Layout change after undo
Steps to Reproduce:
1. Open the attached file
D. on second page.. out of section
User Profile Reset: No
Version: 220.127.116.11.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
Created attachment 167747 [details]
Also found in
CPU-Threads: 4; BS: Windows 6.3; UI-Render: GL;
Gebietsschema: nl-NL (nl_NL); Calc: CL
Created attachment 167755 [details]
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)
parent 41d8ca9686c7c184f586e99674b443c34bfd4f33 (diff)
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
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.
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: 18.104.22.168.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
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 ***