New branch 'feature/cib_contract57l' available with the following commits:
commit 82903656706e22538a8c2b16790a1b7fc0fa5eb1
Author: Michael Stahl <[email protected]>
Date: Thu May 6 18:20:14 2021 +0200
tdf#138518 sw: layout: fix assert on ooo43913-1.doc
Assertion `rAnchoredObjPage.GetPhyPageNum() == _nFromPageNum' failed.
Because not only the fly's anchor frame moves forward in
FormatAnchorFrameForCheckMoveFwd(), but also the fly itself,
apparently because it's in a table:
0 SwAnchoredObject::SetPageFrame(SwPageFrame*) (this=0x5a1d3d8,
_pNewPageFrame=0x8cfbeb0) at sw/source/core/layout/anchoredobject.cxx:162
1 SwPageFrame::MoveFly(SwFlyFrame*, SwPageFrame*) (this=0x8cbd8c0,
pToMove=0x5a1d280, pDest=0x8cfbeb0) at sw/source/core/layout/flylay.cxx:985
2 lcl_ArrangeLowers(SwLayoutFrame*, tools::Long, bool) (pLay=0x8cf80c0,
lYStart=179488, bInva=false) at sw/source/core/layout/tabfrm.cxx:5000
3 SwCellFrame::Format(OutputDevice*, SwBorderAttrs const*)
(this=0x8cf80c0, pAttrs=0x8ce78c0) at sw/source/core/layout/tabfrm.cxx:5359
4 SwLayoutFrame::MakeAll(OutputDevice*) (this=0x8cf80c0) at
sw/source/core/layout/calcmove.cxx:1036
5 SwFrame::PrepareMake(OutputDevice*) (this=0x8cf80c0,
pRenderContext=0x5b7fcf0) at sw/source/core/layout/calcmove.cxx:375
6 SwFrame::Calc(OutputDevice*) const (this=0x8cf80c0,
pRenderContext=0x5b7fcf0) at sw/source/core/layout/trvlfrm.cxx:1792
7 SwFrame::MakePos() (this=0x8cebdb0) at
sw/source/core/layout/calcmove.cxx:627
8 SwTextFrame::MakePos() (this=0x8cebdb0) at
sw/source/core/text/frmform.cxx:340
9 SwContentFrame::MakeAll(OutputDevice*) (this=0x8cebdb0) at
sw/source/core/layout/calcmove.cxx:1412
10 SwFrame::PrepareMake(OutputDevice*) (this=0x8cebdb0,
pRenderContext=0x5b7fcf0) at sw/source/core/layout/calcmove.cxx:286
11 SwFrame::Calc(OutputDevice*) const (this=0x8cebdb0,
pRenderContext=0x5b7fcf0) at sw/source/core/layout/trvlfrm.cxx:1792
12 SwTextFrame::CalcFollow(o3tl::strong_int<int, Tag_TextFrameIndex>)
(this=0x5ae2c60, nTextOfst=...) at sw/source/core/text/frmform.cxx:279
13 SwTextFrame::AdjustFollow_(SwTextFormatter&, o3tl::strong_int<int,
Tag_TextFrameIndex>, o3tl::strong_int<int, Tag_TextFrameIndex>, unsigned char)
(this=0x5ae2c60, rLine=..., nOffset=..., nEnd=..., nMode=1 '\001') at
sw/source/core/text/frmform.cxx:611
14 SwTextFrame::FormatAdjust(SwTextFormatter&, WidowsAndOrphans&,
o3tl::strong_int<int, Tag_TextFrameIndex>, bool) (this=0x5ae2c60, rLine=...,
rFrameBreak=..., nStrLen=..., bDummy=false) at
sw/source/core/text/frmform.cxx:1166
15 SwTextFrame::Format_(SwTextFormatter&, SwTextFormatInfo&, bool)
(this=0x5ae2c60, rLine=..., rInf=..., bAdjust=false) at
sw/source/core/text/frmform.cxx:1613
16 SwTextFrame::Format_(OutputDevice*, SwParaPortion*) (this=0x5ae2c60,
pRenderContext=0x5b7fcf0, pPara=0x8d07490) at
sw/source/core/text/frmform.cxx:1720
17 SwTextFrame::Format(OutputDevice*, SwBorderAttrs const*)
(this=0x5ae2c60, pRenderContext=0x5b7fcf0) at
sw/source/core/text/frmform.cxx:1910
18 SwContentFrame::MakeAll(OutputDevice*) (this=0x5ae2c60) at
sw/source/core/layout/calcmove.cxx:1525
19 SwFrame::PrepareMake(OutputDevice*) (this=0x5ae2f80,
pRenderContext=0x5b7fcf0) at sw/source/core/layout/calcmove.cxx:321
20 SwFrame::Calc(OutputDevice*) const (this=0x5ae2f80,
pRenderContext=0x5b7fcf0) at sw/source/core/layout/trvlfrm.cxx:1792
21 SwObjectFormatterTextFrame::FormatAnchorFrameAndItsPrevs(SwTextFrame&)
(_rAnchorTextFrame=...) at sw/source/core/layout/objectformattertxtfrm.cxx:905
22 SwObjectFormatterTextFrame::FormatAnchorFrameForCheckMoveFwd()
(this=0x8ce5720) at sw/source/core/layout/objectformattertxtfrm.cxx:919
23 SwObjectFormatterTextFrame::DoFormatObjs() (this=0x8ce5720) at
sw/source/core/layout/objectformattertxtfrm.cxx:368
24 SwObjectFormatter::FormatObjsAtFrame(SwFrame&, SwPageFrame const&,
SwLayAction*) (_rAnchorFrame=..., _rPageFrame=..., _pLayAction=0x0) at
sw/source/core/layout/objectformatter.cxx:160
25 SwContentFrame::CalcLowers(SwLayoutFrame&, SwLayoutFrame const&, long,
bool) (rLay=..., rDontLeave=..., nBottom=192048, bSkipRowSpanCells=true) at
sw/source/core/layout/tabfrm.cxx:1534
26 lcl_RecalcRow(SwRowFrame&, tools::Long) (rRow=..., nBottom=192048) at
sw/source/core/layout/tabfrm.cxx:1653
27 SwTabFrame::MakeAll(OutputDevice*) (this=0x8cf5f80,
pRenderContext=0x5b7fcf0) at sw/source/core/layout/tabfrm.cxx:2425
It looks like the _nFromPageNum is always from the
SwObjectFormatter::mrPageFrame anyway because that's a precondition of
the mpPgNumAndTypeOfAnchors->Collect() being called, so just rely on
that to get the correct page.
(regression from c799de145f7e289f31e3669646e5bd12814e6c5e)
Change-Id: Ibdffb2121cffbc04320d17a29ab2e160dec4250b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115188
Tested-by: Jenkins
Reviewed-by: Michael Stahl <[email protected]>
(cherry picked from commit 533a998e540b0f04068c876dde0e74adc3f79c93)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115201
Reviewed-by: Caolán McNamara <[email protected]>
(cherry picked from commit 7eb12f8a09dd67168ba42058b99d8ab58a5c7b0a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115766
Tested-by: Michael Stahl <[email protected]>
commit fa1d7e623ab1e5ca51d1f592c6484ac38b6edb18
Author: Michael Stahl <[email protected]>
Date: Thu Apr 22 13:43:07 2021 +0200
tdf#138518 sw: layout: avoid moving flys forward prematurely
(regression from b9ef71476fd70bc13f50ebe80390e0730d1b7afb
"tdf#134298 sw: layout: remove left-over page frame without content")
When updating the 3rd ToX, the change to remove empty page frames
causes one page frame to be deleted.
On the subsequent layout, things generally move backward, but there are
some fly-related hiccups; the first problem is visible on page 7.
Commit eb85de8e6b61fb3fcb6c03ae0145f7fe5478bccf
"sw: layout: if fly's anchor moves forward, move fly off SwPageFrame"
helps quite a bit, but not completely; now the first problem happens on
page 54, when SwTextFrame 1261 and its fly 3132 are formatted.
Frame 1261 moves forward to page 55, and then
SwObjectFormatterTextFrame::CheckMovedFwdCondition() returns true and so
SwMovedFwdFramesByObjPos::Insert() is called to prevent frame 1261 from
moving back to page 54.
But the reason why it moved forward is that there are 3 flys on page 54
that are anchored on frames in the next-chain of 1261, namely 1275,
1283 and 1284; if these flys weren't on the page then 1261 would fit.
While the move forward cannot be easily prevented in the situation, it's
possible to avoid the entry into the SwMovedFwdFramesByObjPos map,
by detecting that there are flys on the page that would should forward
*before* the current one does.
With this fix and the above mentioned commit to get the flys off the
page, frame 1261 will eventually move back to page 54 again.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114478
Tested-by: Jenkins
Reviewed-by: Michael Stahl <[email protected]>
(cherry picked from commit c799de145f7e289f31e3669646e5bd12814e6c5e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114521
Reviewed-by: Thorsten Behrens <[email protected]>
(cherry picked from commit 8feac9601cfe35ee0966776bab15d122206f154e)
tdf#138518 sw: layout: unbreak fdo80206-1.doc
The 7 flys on the para on page 3 create ~15 extra pages with one
paragraph each.
Argh! One of the bPageHasFlysAnchoredBelowThis checks was inverted.
How dumb of me.
(regression from c799de145f7e289f31e3669646e5bd12814e6c5e)
Still doesn't look good but now it looks same as in 7.0.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115242
Reviewed-by: Michael Stahl <[email protected]>
Tested-by: Jenkins
(cherry picked from commit 59d96acec8c4d9e472daa3e2c287b3a754e01817)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115206
Reviewed-by: Caolán McNamara <[email protected]>
(cherry picked from commit dcea18e66e61c6f411b9bf6498a0ffc374161484)
Change-Id: I83e44d65a0b889a49a313b0cd8b08efce4c3afa7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115765
Tested-by: Michael Stahl <[email protected]>
Reviewed-by: Michael Stahl <[email protected]>
commit ce274e8eaf738aa62a15c6ddb3a6b9eebc6d5119
Author: Michael Stahl <[email protected]>
Date: Tue Apr 13 20:13:51 2021 +0200
sw: layout: if fly's anchor moves forward, move fly off SwPageFrame
The problem is that on Show Changes->Hide Changes->Show Changes
in a 311 page document, the fly "Grafik1" was initially on page 203
but ends up on page 204, with a fly-sized gap on page 194.
In a 25 page cut down version of the bugdoc, on layout action 659
the fly's anchor SwTextFrame moves from page 21 to page 22, but
the fly remains in the SwPageFrame's m_pSortedObjs, because it's
not the anchor frame itself that moves but a distant previous frame,
and page 21 goes valid.
0 SwFlowFrame::PasteTree(SwFrame*, SwLayoutFrame*, SwFrame*, SwFrame*)
(pStart=0x57c9e30, pParent=0xba15c50, pSibling=0x5a0f920, pOldParent=0xb057690)
at sw/source/core/layout/flowfrm.cxx:586
1 SwFlowFrame::MoveSubTree(SwLayoutFrame*, SwFrame*) (this=0x57c9f48,
pParent=0xba15c50, pSibling=0x5a0f920) at sw/source/core/layout/flowfrm.cxx:677
2 SwFlowFrame::MoveFwd(bool, bool, bool) (this=0x57c9f48, bMakePage=true,
bPageBreak=false, bMoveAlways=false) at sw/source/core/layout/flowfrm.cxx:2061
3 SwContentFrame::MakeAll(OutputDevice*) (this=0x57c9e30) at
sw/source/core/layout/calcmove.cxx:1831
4 SwFrame::OptPrepareMake() (this=0x57c9e30) at
sw/source/core/layout/calcmove.cxx:399
5 SwFrame::OptCalc() const (this=0x57c9e30) at
sw/source/core/inc/frame.hxx:1065
6 SwLayAction::FormatContent_(SwContentFrame const*, SwPageFrame const*)
(this=0x7ffec0191b30, pContent=0x57c9e30, pPage=0xb9a1fd0) at
sw/source/core/layout/layact.cxx:1833
In subsequent layout actions the anchor frame moves forward one
page at a time, until in action 665, when things get really interesting.
On page 24, the anchor text frame 582 is formatted for the first time,
and it moves the fly to page 24, after positioning it on the page.
2 SwPageFrame::MoveFly(SwFlyFrame*, SwPageFrame*) (this=0xb9a1fd0,
pToMove=0x641d310, pDest=0x9125bb0) at sw/source/core/layout/flylay.cxx:972
3 SwFlyAtContentFrame::RegisterAtCorrectPage() (this=0x641d310) at
sw/source/core/layout/flycnt.cxx:1432
4 SwAnchoredObject::SetVertPosOrientFrame(SwLayoutFrame const&)
(this=0x641d468, _rVertPosOrientFrame=...) at
sw/source/core/layout/anchoredobject.cxx:195
5 SwFlyAtContentFrame::MakeObjPos() (this=0x641d310) at
sw/source/core/layout/flycnt.cxx:1466
6 SwFlyFreeFrame::MakeAll(OutputDevice*) (this=0x641d310) at
sw/source/core/layout/flylay.cxx:223
7 SwFlyAtContentFrame::MakeAll(OutputDevice*) (this=0x641d310,
pRenderContext=0x55b1f00) at sw/source/core/layout/flycnt.cxx:384
8 SwFrame::PrepareMake(OutputDevice*) (this=0x641d310,
pRenderContext=0x55b1f00) at sw/source/core/layout/calcmove.cxx:375
9 SwFrame::Calc(OutputDevice*) const (this=0x641d310,
pRenderContext=0x55b1f00) at sw/source/core/layout/trvlfrm.cxx:1791
10 SwFlyFrame::Calc(OutputDevice*) const (this=0x641d310,
pRenderContext=0x55b1f00) at sw/source/core/layout/fly.cxx:2874
11 SwLayAction::FormatLayoutFly(SwFlyFrame*) (this=0x7ffec0191b30,
pFly=0x641d310) at sw/source/core/layout/layact.cxx:1455
12 SwObjectFormatter::FormatObj_(SwAnchoredObject&) (this=0xa5c0d10,
_rAnchoredObj=...) at sw/source/core/layout/objectformatter.cxx:286
13 SwObjectFormatterTextFrame::DoFormatObj(SwAnchoredObject&, bool)
(this=0xa5c0d10, _rAnchoredObj=..., _bCheckForMovedFwd=false) at
sw/source/core/layout/objectformattertxtfrm.cxx:135
14 SwObjectFormatter::FormatObjsAtFrame_(SwTextFrame*) (this=0xa5c0d10,
_pMasterTextFrame=0x0) at sw/source/core/layout/objectformatter.cxx:408
15 SwObjectFormatterTextFrame::DoFormatObjs() (this=0xa5c0d10) at
sw/source/core/layout/objectformattertxtfrm.cxx:337
16 SwObjectFormatter::FormatObjsAtFrame(SwFrame&, SwPageFrame const&,
SwLayAction*) (_rAnchorFrame=..., _rPageFrame=..., _pLayAction=0x7ffec0191b30)
at sw/source/core/layout/objectformatter.cxx:160
17 SwLayAction::FormatContent(SwPageFrame const*) (this=0x7ffec0191b30,
pPage=0x9125bb0) at sw/source/core/layout/layact.cxx:1675
18 SwLayAction::InternalAction(OutputDevice*) (this=0x7ffec0191b30,
pRenderContext=0x55b1f00) at sw/source/core/layout/layact.cxx:771
Nothing invalidates page 21 now that the fly is gone, and formatting
on page 24 is kind of pointless now because everything from page 21
on is wrongly positioned. (It's possible to skip out of the main layout
action loop via SetNextCycle()/IsAgain(), but at this point it's in
layact:771 in the layout-all-the-visible-pages loop that follows
the main loop, and that one can't be cancelled.)
Then DoFormatObjs() is called on frame 582, and this calls
FormatAnchorFrameForCheckMoveFwd(), which formats previous frame 581,
splitting it and moving its follow along with 582 to page 25.
Here SwMovedFwdFramesByObjPos::Insert() is called, and now the anchor
text frame 582 cannot move back to page 24 because it's prevented by
SwMovedFwdFramesByObjPos::FrameMovedFwdByObjPos(), but that was all
based on the wrong assumption that the pages before 24 were
completely formatted (this happens in action 670).
Something later formats page 21 again, and so at the end there is a
fly-sized hole at the bottom of page 24, with frame 582 at the top
of page 25.
It won't help to detect a situation where the fly is on a page previous
to the page it's anchor frame is on in DoFormatObjs() because it was
actually moved to the same page in a previous formatting of the anchor
frame, in the same layout action.
To fix this, try to detect in SwLayAction::FormatContent() if the
anchor frame of any fly on the page has moved forward, and move those
flys off the page; this is enough for the 25 page document.
The 311 page document still has a hole on page 194 though; apparently
the last content frame on the page is never reformatted, so
invalidate its size.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114066
Tested-by: Jenkins
Reviewed-by: Michael Stahl <[email protected]>
(cherry picked from commit eb85de8e6b61fb3fcb6c03ae0145f7fe5478bccf)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114519
Reviewed-by: Thorsten Behrens <[email protected]>
(cherry picked from commit 810f7e4e0b61ee7cb3a7d6a1b503782d7248a4b1)
tdf#141945 sw: layout: check master frame when moving fly forward
The problem is that in the finished layout the fly frames are
positioned on the first page but are in SwPageFrame::m_pSortedObjs
of the second page.
Don't use FindPageFrameOfAnchor() because that looks up the follow-frame
that contains the anchor position. This was unintentional; the idea
was to get flys anchored in subsequent paragraphs out of the way.
This situation where it's on a follow-frame of the same paragraph is
more complicated and less obvious, so don't try to solve it now.
(regression from eb85de8e6b61fb3fcb6c03ae0145f7fe5478bccf)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115100
Tested-by: Jenkins
Reviewed-by: Michael Stahl <[email protected]>
(cherry picked from commit 30512746c182b52f37f9a818d4e206c98e715cb7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115080
Reviewed-by: Caolán McNamara <[email protected]>
(cherry picked from commit 41f68b652eb1ccdd4941e2270426461da8e66417)
Change-Id: I232c6b305e8593bfecd885c36058777f3980f82f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115763
Tested-by: Michael Stahl <[email protected]>
Reviewed-by: Michael Stahl <[email protected]>
commit 36efc6acd2bff211ce44a62ef36d3bb3dd4c173c
Author: Michael Stahl <[email protected]>
Date: Fri Nov 13 20:51:42 2020 +0100
tdf#138039 tdf#134298 sw: layout: fix overlap of fly and table
The layout is horribly borked, the fly anchored in the body-level
paragraph messed with the preceding table:
page id="1" top="284" width="11905" height="16837" bottom="17120"
tab id="3" top="794"
row id="4" top="17121"
fly id="8" top="16725"
txt id="7" top="1394"
fly ptr="0x6ce5510" id="10" top="1302"
SwTabFrame::CalcFlyOffsets() detects an overlap with the large fly, and
since it has wrap NONE it resizes to below the large image.
Then the SwTabFrame doesn't fit on the page, so it is split, but the split
fails because nDistanceToUpperPrtBottom is -720 (negative); hence it is
joined again.
Meanwhile the fly was invalidated, so now CalcFlyOffsets() ignores it and
the table shrinks again.
Once the fly is positioned again, the process repeats from the start.
Fix this in SwTabFrame::CalcFlyOffsets() by ignoring flys with wrap NONE
that
extend below the body of the document and are anchored in a frame in the
next-chain of the table frame: these must move to the next page with their
anchor frame.
For the bugdoc this gives the same layout as LO 5.2.
Reportedly this problem started to happen since commit
6f5024de2e1a5cc533527e45b33d9a415467c48d, but it's not obvious why.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105809
Tested-by: Jenkins
Reviewed-by: Michael Stahl <[email protected]>
(cherry picked from commit 6b92d2e8522ecc98d2c5532f5076c20ae295168e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105940
Tested-by: Michael Stahl <[email protected]>
Change-Id: Iafb8a6afcba634f11c5db73869313ded0fe13bbd
commit b324e5a9956ec039f7d111025d95afd7a6fcd038
Author: Michael Stahl <[email protected]>
Date: Tue Apr 20 12:45:36 2021 +0200
tdf#138785 sw: fix mis-positioned as-char flys when deleting empty page
When SwFrame::CheckPageDescs() deletes an empty page in the middle of
the document, which happens during SetRedlineFlags() here, the
SwFlyInContentFrame::maFrameArea is moved in lcl_MoveAllLowers(), but
the SwFlyInContentFrame::m_aRefPoint stays unchanged.
Because the formatting occurs only after the redline mode is reset, the
position of the SwFlyInContentFrame when it is formatted is exactly the
same as its (stale) m_aRefPoint, so the setting of (updated) maFrameArea
is skipped in SwAsCharAnchoredObjectPosition::CalcPosition(), so the
fly ends up a page above where it should be.
So keep m_aRefPoint consistent with maFrameArea in lcl_MoveAllLowers().
(regression from b9ef71476fd70bc13f50ebe80390e0730d1b7afb)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114332
Tested-by: Jenkins
Reviewed-by: Michael Stahl <[email protected]>
(cherry picked from commit e656cf2a71e738c282abcd0d610e724b955f274a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114520
Reviewed-by: Thorsten Behrens <[email protected]>
(cherry picked from commit c79b92edfb5e650fff76688998cf4f0bbd08d2a4)
Change-Id: If1b421daa0d71718d89d9772f5c0d9e367e76845
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115764
Tested-by: Michael Stahl <[email protected]>
Reviewed-by: Michael Stahl <[email protected]>
commit 38b997ebdd80e5a652bba3e24760e704d0f0e3ea
Author: Michael Stahl <[email protected]>
Date: Fri Nov 13 20:52:28 2020 +0100
tdf#134298 sw: layout: remove left-over page frame without content
Once tdf#138039 is fixed, this bugdoc has an additional empty page 3.
This is because it first goes to 3 pages, and then the SwTextFrame
on page does a MoveBwd, leaving behind a page frame with just a body
frame and nothing else.
It turns out that SwRootFrame::RemoveSuperfluous() only removes
empty frames at the end of the document, but here there's a non-empty
frame following it. Also, this function doesn't handle cases like
right/left page styles so it can't delete pages in the middle.
SwFrame::CheckPageDescs() doesn't remove page frames that don't have
content, it only removes those that have the intentionally-empty flag set.
Extend CheckPageDescs() to also remove page frames that don't have
content, and make sure it is called when SwContentFrame::Cut()
removes the last content from a page frame (it will be called after
all pages are valid in SwLayAction::InternalAction()).
(Alternatively it might be possible to prevent the problem from
occurring in SwTextFly::ForEach() by ignoring the fly so that the first
paragraph never leaves page 1, but we didn't explore that.)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105810
Tested-by: Jenkins
Reviewed-by: Michael Stahl <[email protected]>
(cherry picked from commit b9ef71476fd70bc13f50ebe80390e0730d1b7afb)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114097
Tested-by: Michael Stahl <[email protected]>
Reviewed-by: Michael Stahl <[email protected]>
Change-Id: I3a3f1efe6d7ed28e05dc159a86abc3d702cc272b
commit 83f5910e5703edccee77d6aaf554fd1586fe1e49
Author: Michael Stahl <[email protected]>
Date: Mon Nov 16 13:08:48 2020 +0100
(related tdf#134298) sw: layout: avoid infinite loop in InternalAction()
The condition IsInterrupt() && pPage && (m_nCheckPageNum != USHRT_MAX)
isn't handled properly and the while loop will never terminate with
the fix for tdf#134298 in several UITest_writer_tests*.
If m_nCheckPageNum is set, then it must result in a call to
CheckPageDescs() here; it's a member of SwLayAction so won't survive
until the next idle layout invocation.
There is a funny history of these loop conditions with
commit 9eff9e699e17cc5a8a25895bd28dc8e4ceb8071e
and cee296066ab780217395201ab84c2150c8840d25 so we can only hope
this time we got it right...
Change-Id: I91b63540bf4280296d747cb8e841594f8dd3b140
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105927
Tested-by: Jenkins
Reviewed-by: Michael Stahl <[email protected]>
(cherry picked from commit 094ee3955ee81e1bc631d50cc216cbb17a777839)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114096
Tested-by: Michael Stahl <[email protected]>
Reviewed-by: Michael Stahl <[email protected]>
commit 04110639fdbafb749819396177c11ba67b601aec
Author: Michael Stahl <[email protected]>
Date: Thu Dec 2 10:35:20 2021 +0100
nss: upgrade to release 3.73
Fixes:
CVE-2021-43527 Memory corruption via DER-encoded DSA and RSA-PSS signatures
Change-Id: I5c3f169c57fc2763029b07ad7e325b2f53b7e28f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126218
Tested-by: Thorsten Behrens <[email protected]>
Reviewed-by: Thorsten Behrens <[email protected]>
