Age | Commit message (Collapse) | Author |
|
since:
commit 2d6addb180ad30383f4aaec198c22ccbf936fa87
CommitDate: Mon Oct 21 15:16:57 2024 +0200
tdf#163486 sw: PVS: identical sub-expressions
Change-Id: I601a72a8a39f3591d1110f65a027e89923befaca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175702
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Copypasta in commit c799de145f7e289f31e3669646e5bd12814e6c5e, we want to
compare the rows where the 2 objects are anchored.
Change-Id: Ifdf267b8d70d6410ce50a507783d284ac128c1aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175326
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
|
|
make this an assert, it will crash and burn anyway if its not > 0
Change-Id: Id4780efbae45e984a162df182c3297536546bf04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173425
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I68acd56b28b0f989a4010cd939f2452970d158ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167103
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
The problem is that when moving images around the code tries
to do things with anchored text frames that have already gone
through destruction. The fix is to check if those frames have
the destruction bit set before using them, thus avoiding the
crashes.
Also, there is an assert that was firing and removing it
seems to have no negative effect in interacting with the file.
Change-Id: I899171ef3b5113f479725b0421f469c36e40e26c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162151
Reviewed-by: Matt K <mattkse@gmail.com>
Tested-by: Matt K <mattkse@gmail.com>
|
|
In commit 19062c98da5b2e9edc7a99068fa06a83c7578826, it was important to
check if objects have frame format before using GetFrameFormat.
Thic change makes it simpler amd more obvious. Also, it allows to avoid
two calls to GetUserCall, by obtaining the pointer once and checking it.
Change-Id: I980fcba9e369e107f3d062e8cab0a34e02384290
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162044
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Id81729de2efd6f65f1b51bdb437ca21a260eaf6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132143
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
See tdf#42949 for motivation
Change-Id: I8a8df68946297fad517b753d73e4373203a45ed6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132150
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I1e12def63a6353a9eab3f073ef35ba305ff32649
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130829
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
This reverts commit fe5d3fbfe63fe8b433776bd3a0508dd712b868b0
It turns out that checking a single column's IsMovingFootnotes() is not
enough - as frames can move both forwards and backwards the entire chain
of columns would need to be checked.
(Most callers of MoveLowerFootnotes() move forwards, but one place in
tabfrm.cxx moves from a follow to master.)
But it turns out that this is probably the wrong way in any case: most
likely the intention in FormatAnchorFrameAndItsPrevs() is to format
previous frames in the same layout environment, so if there is a section
or column inside a footnote then this upper should be formatted, while
if the footnote is inside a section or column this upper should not be
formatted; this should make calls during MoveFootnotes_() safe as it
should prevent the formatting of frames in the footnote boss moving a
footnote that is already being moved.
So tweak the fix in commit fa1bcc22921941b2cd8a0b32fe0d15655d12d607
a little to make it more general.
Also it was previously possible that for a section with columns,
both the section branch and the column branch was taken, which seems
supperfluous.
Change-Id: I39487640322339fe4d511e845d9c6bced2ba9dad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130544
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: Ifebe53956ca0a7d3653469256c895a666cfffbf8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130439
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
no logic change intended
Change-Id: Ib0174f8040faa3efde7b9c5ba9b062bac5a35da3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118983
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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.
Change-Id: Ib10c46f48746362d8d679c147ddc8b85157be508
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115242
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
|
|
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 <michael.stahl@allotropia.de>
|
|
(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.
Change-Id: I83e44d65a0b889a49a313b0cd8b08efce4c3afa7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114478
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: Ib7a895fba66f8dc9b6501e61631c02694053b7fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113157
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
a trawl of crash testing document didn't show up another example
and it doesn't seem possible to create this scenario directly in out
UI
Change-Id: Ie65a51bf609e8bacd261f368f0b8037431c116ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112567
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Follow-up to commit c9eb53f200225f2ee6ca695e1326843a487aee51
(tdf#135198 sw editing: text box fell out of its shape)
Every time a shape is repositioned, make sure the text box
inside the shape follows the shape.
The previous solution to this bug, the one implemented in
SwObjectFormatterTextFrame::DoFormatObjs, was a little
more cumbersome. This one should produce fewer regressions,
I hope.
Change-Id: I3e88eb8616cd299cabb7b74b188ab7220746ec89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106421
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I4bb84c3f401aba8a3dede9cec3a7f2187a2ba02a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106473
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This reverts commit f2eef84ff03660cbb46a76c317e640e054ed0a56.
Reason for revert: https://bugs.documentfoundation.org/show_bug.cgi?id=135198#c9
This also reverts part of 768cfcee178b284be6d96d384364e59e40ecb375
without breaking tdf#137960 nor tdf#137964
Change-Id: Ifa418e66b8a45c6204babfae6513ca67aed93289
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105545
Reviewed-by: Dániel Arató <arato.daniel@nisz.hu>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
A text box and its including shape are now going to keep their
positions in sync along the horizontal (X) axis as well as the
vertical (Y) axis.
Moreover, Shift-UpArrow, Shift-DownArrow, Shift-LeftArrow and
Shift-RightArrow are all going to work the same as the plain
arrow keys, they are just going to move the text a larger
distance.
Change-Id: I49482a101d97927715f47efbf0f58808ea6a8547
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105328
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
from commit c9eb53f200225f2ee6ca695e1326843a487aee51
(tdf#135198 sw editing: text box fell out of its shape).
The height of the bottom text box frame from the tdf#117921 sample
file grew unreasonably large. This is countered by only activating
the previous fix if it is strictly needed, i.e. when a shape and
its text box drift apart from each other.
The test file is derived from the one used for tdf#117921.
Change-Id: Ied01c6089efe586b73de559f89f08b958f4b62d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105238
Tested-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
this is from a failed campaign against tdf#122894
Change-Id: I639d65394cadca6ca70613dfd13691fd7b5f5104
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105191
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
since...
commit c9eb53f200225f2ee6ca695e1326843a487aee51 (HEAD, refs/bisect/bad)
Date: Wed Oct 14 15:46:23 2020 +0200
tdf#135198 sw editing: text box fell out of its shape
I don't think layout should add into the undo stack
Change-Id: I92e154dbe2396ff4085fffd7e962e43d2c61c073
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105045
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Without this patch if a shape anchored to a paragraph and containing
a text box was moved upwards beyond the vertical position of its anchor,
the text box failed to keep its position in sync with the shape.
This is fixed by telling the text box the absolute vertical position of
the corresponding shape after the latter is moved.
Note: Other fix is associated to the shortcut keys
Shift-Arrow Up/Shift-Arrow Down for moving text frames with
bigger steps vertically. Now it's not possible to use these
keys, but that was bad with text boxes, because it moved only
the text content of the text box.
Note: this patch fixes the vertical position of the text box
of textbox-wps-only.docx of the unit test textboxWpsOnly.
Change-Id: Ib66b13cae455462c616fed6bbd088433c83e61a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104520
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
sometimes it doesn't happen to crash, but its always dereferencing
a deleted frame
Change-Id: I056808398c97c5de12542c6c342e7d9d7e5195d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102334
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I67fd1a269d960174b88c57da4a0588f5d9252660
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99885
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9c0968bd93f41f983468ee7ba8a20e27c4866b32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87954
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4e4a1b24d6b19ab62d9f0d73bcd74492bc955beb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86379
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I173b3aaca84a707799f0ee78cddcbd70524897bc
Reviewed-on: https://gerrit.libreoffice.org/82561
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
undo forcepoint80 hackery and try a different solution
Change-Id: I52b5f9b41074e122bd32e70967e198ce9f86aec7
Reviewed-on: https://gerrit.libreoffice.org/76072
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iad5770b512d7c49483ac823aa4f51212f281bbca
Reviewed-on: https://gerrit.libreoffice.org/61628
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I549173b942de19eb3ff1e74fdee6e72de720988f
Reviewed-on: https://gerrit.libreoffice.org/60373
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5ce4590af52b3bfc08f89915999e86f4973fa9e3
|
|
Isolated all Frame AreaDefinition and it's layout flags to
SwFrameAreaDefinition class which is now base for SwFrame.
Adapted calls to get/set and WriteAccess hekper classes accordingly.
This allows much deeper understanding what Writer is doing when
layouting it's frames and needed when reaction on such changes
is necessary
Change-Id: I96220a1d140e69c76cc63023aae26e4ed17f3504
|
|
Change-Id: Ida715fad0c4587a9566184180bf159da12470dd7
Reviewed-on: https://gerrit.libreoffice.org/43207
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I899a8126c9d971601fea6c77eca165718aea0ac5
Reviewed-on: https://gerrit.libreoffice.org/41237
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iae081567c4fa5b88edbd12cf2fbafd2b8f31b300
Reviewed-on: https://gerrit.libreoffice.org/41214
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
After inserting a header in the bugdoc, during SwFrame::Calc of a
SwTextFrame that is in a footnote, it decides move forward to the next
page. This deletes the SwFootnoteFrame and SwFootnoteContFrame that
lcl_FormatContentOfLayoutFrame() are iterating over.
For want of a more elegant solution, use a big hammer to prevent the
problem and try to clean up so that no empty SwFootnoteFrame and
SwFootnoteContFrame remain (as that is known to crash in other places,
see commit c9fb347642729017ad0c613fe26310befd021db8)
Invalid read of size 8
at 0x414E1F96: SwFrame::GetNext() (frame.hxx:485)
by 0x41AFDD07: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:646)
by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642)
by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642)
by 0x41AFDEA7: SwObjectFormatterTextFrame::FormatAnchorFrameAndItsPrevs(SwTextFrame&) (objectformattertxtfrm.cxx:696)
by 0x41AAA680: SwFlyAtContentFrame::MakeAll(OutputDevice*) (flycnt.cxx:415)
by 0x41A7F211: SwFrame::PrepareMake(OutputDevice*) (calcmove.cxx:346)
by 0x41B75758: SwFrame::Calc(OutputDevice*) const (trvlfrm.cxx:1761)
by 0x41AA8927: SwFlyFrame::Calc(OutputDevice*) const (fly.cxx:2559)
by 0x41ADB36B: SwLayAction::FormatLayoutFly(SwFlyFrame*) (layact.cxx:1414)
by 0x41AF9658: SwObjectFormatter::FormatObj_(SwAnchoredObject&) (objectformatter.cxx:321)
by 0x41AFCB6E: SwObjectFormatterTextFrame::DoFormatObj(SwAnchoredObject&, bool) (objectformattertxtfrm.cxx:126)
by 0x41AF9A6A: SwObjectFormatter::FormatObjsAtFrame_(SwTextFrame*) (objectformatter.cxx:443)
by 0x41AFD275: SwObjectFormatterTextFrame::DoFormatObjs() (objectformattertxtfrm.cxx:328)
by 0x41AF924A: SwObjectFormatter::FormatObjsAtFrame(SwFrame&, SwPageFrame const&, SwLayAction*) (objectformatter.cxx:191)
by 0x41ADC213: SwLayAction::FormatContent(SwPageFrame const*) (layact.cxx:1633)
by 0x41AD88DE: SwLayAction::InternalAction(OutputDevice*) (layact.cxx:760)
by 0x41AD7080: SwLayAction::Action(OutputDevice*) (layact.cxx:351)
by 0x41ADE32E: SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) (layact.cxx:2133)
by 0x41FFC97E: SwViewShell::LayoutIdle() (viewsh.cxx:711)
Address 0x505541a8 is 72 bytes inside a block of size 272 free'd
at 0x4C2F21A: operator delete(void*) (vg_replace_malloc.c:576)
by 0x41AD371A: SwFootnoteFrame::~SwFootnoteFrame() (ftnfrm.hxx:52)
by 0x41B5B74C: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:391)
by 0x41A97294: SwFlowFrame::CutTree(SwFrame*) (flowfrm.cxx:406)
by 0x41A979AE: SwFlowFrame::MoveSubTree(SwLayoutFrame*, SwFrame*) (flowfrm.cxx:592)
by 0x41ACFB69: SwContentFrame::MoveFootnoteCntFwd(bool, SwFootnoteBossFrame*) (ftnfrm.cxx:2756)
by 0x41A9B78E: SwFlowFrame::MoveFwd(bool, bool, bool) (flowfrm.cxx:1813)
by 0x41A85864: SwContentFrame::MakeAll(OutputDevice*) (calcmove.cxx:1681)
by 0x41A7F211: SwFrame::PrepareMake(OutputDevice*) (calcmove.cxx:346)
by 0x41B75758: SwFrame::Calc(OutputDevice*) const (trvlfrm.cxx:1761)
by 0x41AFDCFB: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:644)
by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642)
by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642)
by 0x41AFDCC0: lcl_FormatContentOfLayoutFrame(SwLayoutFrame*, SwFrame*) (objectformattertxtfrm.cxx:642)
by 0x41AFDEA7: SwObjectFormatterTextFrame::FormatAnchorFrameAndItsPrevs(SwTextFrame&) (objectformattertxtfrm.cxx:696)
by 0x41AAA680: SwFlyAtContentFrame::MakeAll(OutputDevice*) (flycnt.cxx:415)
by 0x41A7F211: SwFrame::PrepareMake(OutputDevice*) (calcmove.cxx:346)
by 0x41B75758: SwFrame::Calc(OutputDevice*) const (trvlfrm.cxx:1761)
by 0x41AA8927: SwFlyFrame::Calc(OutputDevice*) const (fly.cxx:2559)
by 0x41ADB36B: SwLayAction::FormatLayoutFly(SwFlyFrame*) (layact.cxx:1414)
by 0x41AF9658: SwObjectFormatter::FormatObj_(SwAnchoredObject&) (objectformatter.cxx:321)
by 0x41AFCB6E: SwObjectFormatterTextFrame::DoFormatObj(SwAnchoredObject&, bool) (objectformattertxtfrm.cxx:126)
by 0x41AF9A6A: SwObjectFormatter::FormatObjsAtFrame_(SwTextFrame*) (objectformatter.cxx:443)
by 0x41AFD275: SwObjectFormatterTextFrame::DoFormatObjs() (objectformattertxtfrm.cxx:328)
by 0x41AF924A: SwObjectFormatter::FormatObjsAtFrame(SwFrame&, SwPageFrame const&, SwLayAction*) (objectformatter.cxx:191)
by 0x41ADC213: SwLayAction::FormatContent(SwPageFrame const*) (layact.cxx:1633)
by 0x41AD88DE: SwLayAction::InternalAction(OutputDevice*) (layact.cxx:760)
by 0x41AD7080: SwLayAction::Action(OutputDevice*) (layact.cxx:351)
by 0x41ADE32E: SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) (layact.cxx:2133)
by 0x41FFC97E: SwViewShell::LayoutIdle() (viewsh.cxx:711)
Change-Id: I656cc2303eeccd5eef68ad3b8e81bb0fd47b94fb
|
|
Change-Id: I029ad67dfcbc40f3953adf485957efcbd97f23d0
Reviewed-on: https://gerrit.libreoffice.org/35328
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8afde16343288888d9b1806fae6cba3514812d02
Reviewed-on: https://gerrit.libreoffice.org/35062
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|