Description: Layout change after undo Steps to Reproduce: 1. Open the attached file 2. CTRL+A 3. CTRL+X 4. CTRL+Z Actual Results: D. on second page.. out of section Expected Results: In section Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) Build ID: 32fdb8eb3506bc8dcf013cc713fe8e5debceb940 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 167747 [details] Example file
Also found in 6.3 not in Version: 6.1.6.3 Build-ID: 5896ab1714085361c45cf540f76f60673dd96a72 CPU-Threads: 4; BS: Windows 6.3; UI-Render: GL; Gebietsschema: nl-NL (nl_NL); Calc: CL
Created attachment 167755 [details] Bibisect log Bisected to: author Michael Stahl <Michael.Stahl@cib.de> 2018-08-22 17:09:02 +0200 committer Michael Stahl <Michael.Stahl@cib.de> 2018-09-19 10:18:29 +0200 commit 723728cd358693b8f4bc9d913541aa4479f2bd48 (patch) tree 1ac75a662a46987301ea85d32957eb08f435ffd6 parent 41d8ca9686c7c184f586e99674b443c34bfd4f33 (diff) sw_redlinehide_2: SwUndoDelete This is problematic because of the calls to SplitNode. Ideally we'd want the SplitNode to create merged frames already, but that doesn't seem to be easy to achieve; several problems with this are: 1. the redlines are only restored at the end of UndoImpl 2. even if we store another set of SwRedlineSaveDatas right before the Join (while preventing the first SwRedlineSaveDatas from deleting them), and restore them by passing a closure to SplitNode, there are complaints about empty redlines, and also this case isn't handled properly: f<delete start>o<redline start>o b<redline end>a<redline start>r b<redline end>a<delete end>z So instead, let SplitNode create whatever frames it does, and fix it up at the end manually on the start node's frames. This necessitates delaying the creation of the frames on the moved nodes until the end too. https://cgit.freedesktop.org/libreoffice/core/commit/?id=723728cd358693b8f4bc9d913541aa4479f2bd48
Adding CC: to Michael Stahl 4 reports by me, with 4 different variants all point to 723728cd358693b8f4bc9d913541aa4479f2bd48
(In reply to Telesto from comment #4) > 4 reports by me Would be helpful, if you could add them in "see also". Please make also clear, why bug 138618 is a new bug and not a duplicate (You say it's a variant, so I would treat it a sduplicate then).
(In reply to Dieter from comment #5) > (In reply to Telesto from comment #4) > > 4 reports by me > > Would be helpful, if you could add them in "see also". Please make also > clear, why bug 138618 is a new bug and not a duplicate (You say it's a > variant, so I would treat it a sduplicate then). Pff, lets say behaviour being different. Bug reports are symptom reports of something going wrong. The symptom 'kind of different' the underlying is one and the same. There is a complain headache other about fever next one lost taste, not feeling well, all could point... It's pretty sure somewhere in the undo code. But not a clear visual what the exact cause is. So kind of keeping them around (even separate meta-bug) until developer takes a peak. And concludes everything being one and the same thing over and over. The other approach is duplicating all bugs pointing to the same commit.. And assume it being the same. In principle OK, but not always sure if duplicates are re-checked after the fix. It happens we blindly assume everything with same bibisect result being the same thing, which often true but not always..Out of sight out of mind.. and possible masking number of issues with it. But well both ways of handling it having advantages and disadvantages. And there is no guidelines/ rules of engagement. So feel free to mark everything as a duplicate (or even selectively). No very strong opinion, but tend have those nicely visible. (also easier for searching).. Adding those to see also/meta bug is certainly good.
(In reply to Telesto from comment #6) > Pff, lets say behaviour being different. Bug reports are symptom reports of > something going wrong. The symptom 'kind of different' the underlying is one > and the same. I agree, that the bug is not always directly visible. But when we have the same steps to reproduce, it is a duplicate. Otherwise you could open an infinite number of reports for each bug. @Xisco: I couldn't find a definition of "duplicate". Would be nice to have one to achieve a common understanding. *** This bug has been marked as a duplicate of bug 132738 ***
Sorry, I was to fast with my previous comment I confirm it with Version: 7.2.0.0.alpha0+ (x64) Build ID: c0eee433e079d8e3413f4691607e075b99af92b0 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded I'm not an expert, but I think, there is a problem with copy of the last section. If you paste the copied text, last section gets lost. A similar problem ha been reported in bug 119459. BTW: Problem of missing definition of a duplicate remains.
fixed by commit 2b256c84aa4c063c8161b32a7b424daa28b5741b *** This bug has been marked as a duplicate of bug 136452 ***