Bug 132644 - Table splits differently after save, corrected after click inside table
Summary: Table splits differently after save, corrected after click inside table
Status: RESOLVED DUPLICATE of bug 128437
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.0.3 rc
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-03 15:09 UTC by Telesto
Modified: 2020-05-08 20:40 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
Example file (15.10 KB, application/vnd.oasis.opendocument.text)
2020-05-03 15:10 UTC, Telesto
Details
Bibisect log (2.92 KB, text/plain)
2020-05-03 15:17 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-05-03 15:09:51 UTC
Description:
Table splits differently after save

Steps to Reproduce:
1. Open the attached file
2. Scroll to page 2. If yellow marking is at the end of page 2, OK. if not, click at the orange marking.. it will jump to correct position

Actual Results:
Yellow marked text should be on page 2, but shown on page 3, until click in thable

Expected Results:
No layout change after file opening


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
Version: 7.0.0.0.alpha0+ (x64)
Build ID: b8fb7ecd9cdbe1898c41eaecd9894df8e8f01e25
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: 

also in
6.3 (not jumping, but layout is off)

but not in
6.2 and prior
Comment 1 Telesto 2020-05-03 15:10:10 UTC
Created attachment 160282 [details]
Example file
Comment 2 Telesto 2020-05-03 15:17:28 UTC
Created attachment 160283 [details]
Bibisect log

Bisected to:
author	Michael Stahl <Michael.Stahl@cib.de>	2019-05-08 16:23:25 +0200
committer	Michael Stahl <Michael.Stahl@cib.de>	2019-05-09 10:53:11 +0200
commit cc5916cd314a27b0cc99560ab887480026630a95 (patch)
tree 924f56d1eb105c9e6d71c90cf6291fec6e3f7f60
parent f8b4d371eddd27594d549fb00294c01229a9bd24 (diff)
tdf#124675 sw: fix crash when moving SwTextFrame in table to prev page
The problem is that the SwTabFrame and SwRowFrame that are being
iterated are deleted:

 7 SwFrame::DestroyFrame(SwFrame*) (pFrame=0x79052c0) at sw/source/core/layout/ssfrm.cxx:386
 8 SwTabFrame::RemoveFollowFlowLine() (this=0x5bf07d0) at sw/source/core/layout/tabfrm.cxx:907
 9 SwTabFrame::MakeAll(OutputDevice*) (this=0x5bf07d0) at sw/source/core/layout/tabfrm.cxx:1839
10 SwFrame::PrepareMake(OutputDevice*) (this=0x5bf07d0) at sw/source/core/layout/calcmove.cxx:344
11 SwFrame::Calc(OutputDevice*) const (this=0x5bf07d0) at sw/source/core/layout/trvlfrm.cxx:1790
12 SwFrame::PrepareMake(OutputDevice*) (this=0x603a570) at sw/source/core/layout/calcmove.cxx:247
13 SwFrame::Calc(OutputDevice*) const (this=0x603a570) at sw/source/core/layout/trvlfrm.cxx:1790
14 SwFrame::PrepareMake(OutputDevice*) (this=0x5daf120) at sw/source/core/layout/calcmove.cxx:247
15 SwFrame::Calc(OutputDevice*) const (this=0x5daf120) at sw/source/core/layout/trvlfrm.cxx:1790
16 SwFrame::PrepareMake(OutputDevice*) (this=0x6005ca0) at sw/source/core/layout/calcmove.cxx:247
17 SwFrame::Calc(OutputDevice*) const (this=0x6005ca0) at sw/source/core/layout/trvlfrm.cxx:1790
18 SwFrame::MakePos() (this=0x6094330) at sw/source/core/layout/calcmove.cxx:490
19 SwTextFrame::MakePos() (this=0x6094330) at sw/source/core/text/frmform.cxx:343
20 SwContentFrame::MakeAll(OutputDevice*) (this=0x6094330) at sw/source/core/layout/calcmove.cxx:1346
21 SwFrame::OptPrepareMake() (this=0x6094330) at sw/source/core/layout/calcmove.cxx:368
22 SwFrame::OptCalc() const (this=0x6094330) at sw/source/core/inc/frame.hxx:1060
23 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x8a349c0, bAddRect=false) at sw/source/core/layout/layact.cxx:1362
24 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x79052c0, bAddRect=false) at sw/source/core/layout/layact.cxx:1357
25 SwLayAction::FormatLayoutTab(SwTabFrame*, bool) (this=0x7ffc6da48350, pTab=0x7a9c300, bAddRect=false) at sw/source/core/layout/layact.cxx:1569
26 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x7c30300, bAddRect=true) at sw/source/core/layout/layact.cxx:1354
27 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x79e1780, bAddRect=true) at sw/source/core/layout/layact.cxx:1357
28 SwLayAction::InternalAction(OutputDevice*) (this=0x7ffc6da48350) at sw/source/core/layout/layact.cxx:546

They are deleted because the last SwTextFrame was moved via MoveBwd() to
the previous page, and is formatted there.
(regression from commit 18765b9fa739337d2d891513f6e2fb7c3ce23b50)

Prevent this via:

* delete-guard for the SwRowFrame - causing RemoveFollowFlowLine() to
  return early (also, let it return false, so the Join() isn't even
  called, although that doesn't make a difference in practice because
  of the next item:)

* join-guard for the SwTabFrame - otherwise tabfrm.cxx:2199 will Join()
  it anyway

This means that when the page with the follow-frame is done formatting,
the empty SwTabFrame with no SwTextFrame in it will remain.  Fortunately
this is not a problem, because due to the moving, the previous page will
be invalid and layact.cxx:613 will iterate to the previous page and
format it again; then tabfrm:2199 of the master SwTabFrame will detect
that the follow SwTabFrame is empty and Join() it.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=cc5916cd314a27b0cc99560ab887480026630a95
Comment 3 Telesto 2020-05-03 15:20:15 UTC

*** This bug has been marked as a duplicate of bug 128437 ***
Comment 4 Telesto 2020-05-08 20:40:00 UTC
Another example file
https://bugs.documentfoundation.org/attachment.cgi?id=160551

Click bottom right cell on first page