[Libreoffice-commits] core.git: Branch 'libreoffice-6-2' - 2 commits - sw/source
Libreoffice Gerrit user
logerrit at kemper.freedesktop.org
Mon Mar 4 23:40:59 UTC 2019
sw/source/core/text/txtfrm.cxx | 2 +-
sw/source/core/text/widorp.cxx | 1 +
sw/source/core/undo/rolbck.cxx | 9 ++++++---
3 files changed, 8 insertions(+), 4 deletions(-)
New commits:
commit a551d277dc07fc0fbb3d58fd66c0686fe531126b
Author: Michael Stahl <Michael.Stahl at cib.de>
AuthorDate: Tue Feb 26 18:47:46 2019 +0100
Commit: Thorsten Behrens <Thorsten.Behrens at CIB.de>
CommitDate: Tue Mar 5 00:40:44 2019 +0100
tdf#122892 sw: fix IsPrepWidow() loop in SwTextFrame::CalcFollow()
The bugdoc loops on calculating the follow of SwTextFrame 560, the one
containing "Hiermit nehme ich das Angebot an" in a cell with rowspan 3,
while the table is being split and its first row (also now its last
i.e. split row) is being formatted.
Loop in CalcFollow() because the follow is in the same upper frame as
its master and cannot move forward, so the 2nd call to pMyFollow->Calc()
after pMyFollow->Prepare() always sets the SetPrepWidows() flag on the
master and in that case the loop never terminates.
The problem is that the check in WidowsAndOrphans::FindWidows() of
GetThisLines() uses stale cached data - the value returned is 4, but
the frame contains fewer lines at that point and doesn't have lines to
spare for the follow; the cached value is only updated at the end of
SwTextFrame::Format(). Fix it by calling ChgThisLines() here.
But this fix only helps for the first SwTextFrame in a cell; the next
one with id 561 loops in a similar way. The problem then is that
SwTextFrame::PrepWidows() always calls SetPrepWidows(), even if the
Orphan-rule of the frame prevents it from giving lines to the follow.
Fix this by calling SetPrepWidows() only if lines are removed.
This also helps for the 2 attachments of tdf#118104.
(regression from commit 18765b9fa739337d2d891513f6e2fb7c3ce23b50
particularly the change in SwFrame::IsMoveable()
in the sense that it didn't loop before but there isn't anything
obviously wrong with this commit)
Change-Id: Ia1e5928a6510e68520b29eb265e26ffd0627c52e
Reviewed-on: https://gerrit.libreoffice.org/68402
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl at cib.de>
(cherry picked from commit b7d4418c309c8bc4fd25485dd3a0ea6ad9edf34e)
Reviewed-on: https://gerrit.libreoffice.org/68677
Reviewed-by: Thorsten Behrens <Thorsten.Behrens at CIB.de>
diff --git a/sw/source/core/text/txtfrm.cxx b/sw/source/core/text/txtfrm.cxx
index 64e6749b09d1..7d4e077d58c2 100644
--- a/sw/source/core/text/txtfrm.cxx
+++ b/sw/source/core/text/txtfrm.cxx
@@ -2567,7 +2567,6 @@ void SwTextFrame::PrepWidows( const sal_uInt16 nNeed, bool bNotify )
SwParaPortion *pPara = GetPara();
if ( !pPara )
return;
- pPara->SetPrepWidows();
sal_uInt16 nHave = nNeed;
@@ -2599,6 +2598,7 @@ void SwTextFrame::PrepWidows( const sal_uInt16 nNeed, bool bNotify )
if( bSplit )
{
+ pPara->SetPrepWidows();
GetFollow()->SetOfst( aLine.GetEnd() );
aLine.TruncLines( true );
if( pPara->IsFollowField() )
diff --git a/sw/source/core/text/widorp.cxx b/sw/source/core/text/widorp.cxx
index a2d8761e968f..e1bb0c915e28 100644
--- a/sw/source/core/text/widorp.cxx
+++ b/sw/source/core/text/widorp.cxx
@@ -460,6 +460,7 @@ bool WidowsAndOrphans::FindWidows( SwTextFrame *pFrame, SwTextMargin &rLine )
// i#91421
if ( !pMaster->GetIndPrev() )
{
+ pMaster->ChgThisLines();
sal_uLong nLines = pMaster->GetThisLines();
if(nLines == 0 && pMaster->HasPara())
{
commit 3e674fdca08b40bb18131c2490832647796d1301
Author: Michael Stahl <Michael.Stahl at cib.de>
AuthorDate: Fri Mar 1 18:24:40 2019 +0100
Commit: Thorsten Behrens <Thorsten.Behrens at CIB.de>
CommitDate: Tue Mar 5 00:40:35 2019 +0100
tdf#123313 sw: workaround Undo problem with ToX Update
The problem is that when ToX is updated, CrossRefHeadingBookmarks will
be created for the heading nodes, and SwUndoInsBookmark will be created
at that time, but then nodes will be created for later entries in the
ToX and if the heading is below the ToX then the node index in
SwUndoInsBookmark will not match the node index of the
CrossRefHeadingBookmark.
Thus SwHistoryBookmark::IsEqualBookmark() will cause the mark to be
skipped during Undo instead of deleted, and then it can cause trouble.
Work around that by having SwHistoryBookmark::IsEqualBookmark() not
check the position if it's a CrossRefHeadingBookmark.
Change-Id: I9277978844837accdda35195a863c6163a839b6e
Reviewed-on: https://gerrit.libreoffice.org/68596
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl at cib.de>
(cherry picked from commit 60ea01af8c57f9b03ee1da1196284fa10025c22c)
Reviewed-on: https://gerrit.libreoffice.org/68676
Reviewed-by: Thorsten Behrens <Thorsten.Behrens at CIB.de>
diff --git a/sw/source/core/undo/rolbck.cxx b/sw/source/core/undo/rolbck.cxx
index b8048539f459..51a4bcdd813f 100644
--- a/sw/source/core/undo/rolbck.cxx
+++ b/sw/source/core/undo/rolbck.cxx
@@ -54,6 +54,7 @@
#include <charfmt.hxx>
#include <strings.hrc>
#include <bookmrk.hxx>
+#include <crossrefbookmark.hxx>
#include <memory>
OUString SwHistoryHint::GetDescription() const
@@ -669,9 +670,11 @@ void SwHistoryBookmark::SetInDoc( SwDoc* pDoc, bool )
bool SwHistoryBookmark::IsEqualBookmark(const ::sw::mark::IMark& rBkmk)
{
- return m_nNode == rBkmk.GetMarkPos().nNode.GetIndex()
- && m_nContent == rBkmk.GetMarkPos().nContent.GetIndex()
- && m_aName == rBkmk.GetName();
+ return m_aName == rBkmk.GetName()
+ && ( ( m_nNode == rBkmk.GetMarkPos().nNode.GetIndex()
+ && m_nContent == rBkmk.GetMarkPos().nContent.GetIndex())
+ // tdf#123313 these are created in middle of ToX update
+ || dynamic_cast<sw::mark::CrossRefHeadingBookmark const*>(&rBkmk));
}
More information about the Libreoffice-commits
mailing list