Bug 138618 - SECTION: Layout change after undo (corrected after save & reload)
Summary: SECTION: Layout change after undo (corrected after save & reload)
Status: RESOLVED DUPLICATE of bug 136452
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Michael Stahl (allotropia)
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Section redlinehide-regressions
  Show dependency treegraph
Reported: 2020-12-02 10:09 UTC by Telesto
Modified: 2021-12-20 12:24 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

Example file (19.13 KB, application/vnd.oasis.opendocument.text)
2020-12-02 10:10 UTC, Telesto
Bibisect log (2.73 KB, text/plain)
2020-12-02 11:36 UTC, Telesto

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-12-02 10:09:55 UTC
Layout change after undo

Steps to Reproduce:
1. Open the attached file
2. CTRL+A 

Actual Results:
D. on second page.. out of section

Expected Results:
In section

Reproducible: Always

User Profile Reset: No

Additional Info:
Version: (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
Comment 1 Telesto 2020-12-02 10:10:09 UTC
Created attachment 167747 [details]
Example file
Comment 2 Telesto 2020-12-02 10:12:40 UTC
Also found in

not in
Build-ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU-Threads: 4; BS: Windows 6.3; UI-Render: GL; 
Gebietsschema: nl-NL (nl_NL); Calc: CL
Comment 3 Telesto 2020-12-02 11:36:56 UTC
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.

Comment 4 Telesto 2020-12-02 12:14:33 UTC
Adding CC: to Michael Stahl

4 reports by me, with 4 different variants all point to 723728cd358693b8f4bc9d913541aa4479f2bd48
Comment 5 Dieter 2021-01-02 12:35:03 UTC
(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).
Comment 6 Telesto 2021-01-02 13:52:38 UTC
(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.
Comment 7 Dieter 2021-01-04 08:25:01 UTC Comment hidden (obsolete)
Comment 8 Dieter 2021-01-04 08:37:20 UTC
Sorry, I was to fast with my previous comment

I confirm it with

Version: (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.
Comment 9 Michael Stahl (allotropia) 2021-12-20 12:24:23 UTC
fixed by commit 2b256c84aa4c063c8161b32a7b424daa28b5741b

*** This bug has been marked as a duplicate of bug 136452 ***