774a018...
by
Michael Stahl <email address hidden>
tdf#125475 sw: update SwTextFrames when SwTextLine cache shrinks
SwCache::DeleteObj() may decide to shrink the cache, and then the
SwTextFrame::mnCacheIndex goes stale, because only
SwCacheObj::m_nCachePos is updated.
In this bugdoc, this can happen *inside* SwTextFrame::Format(), where
first it succeeds to find an existing SwTextLine, then some footnotes
anchored in this paragraph are moved around and formatted, creating new
SwTextLines, and SwCache::DeleteObj is called. Later, any access of the
original frame's SwTextLine fails to find it and eventually some null
pointer crash happens.
Newly added SwTextLine::UpdateCachePos() requires that SwTextFrame lives
longer than its SwTextLine; there was another problem with that, because
SwTextFrame::FormatEmpty() was throwing away the mnCacheIndex, which
could then cause a second SwTextLine to be created for the same
SwTextFrame, and the first one is not deleted until it falls to the
bottom of the LRU list.
Apprently for this particular document the problem didn't happen before
commit 3d37463eec0c891243a8971a34903b2da01c9e24 and/or
commit 31ae7509003b1e650463ee1468c0b315ba13efe6 but that is mostly luck.
Reviewed-on: https://gerrit.libreoffice.org/73047
Tested-by: Jenkins
Reviewed-by: Michael Stahl <email address hidden>
(cherry picked from commit 1424d51a44ed2fa8b37b2d132af8a608a170ec8e)
871eeb3...
by
Katarina Behrens <email address hidden>
tdf#83722: don't recycle frame with unmodified template
a frame that contained valid but unmodified document opened from
template or explicitly opened by the user (File > New) was treated
the same as blank document i.e. it was reused and the content was
overwritten by newly opened document (even if it already had
non-empty content provided by the template).
So let's not do that and let's open a new document in a new frame
instead
Change-Id: I10252d114e8cc5fcad3c98194ef07fd59873d6da
Reviewed-on: https://gerrit.libreoffice.org/71919
Tested-by: Jenkins
Reviewed-by: Michael Stahl <email address hidden>
Reviewed-by: Katarina Behrens <email address hidden>
911c76f...
by
Michael Stahl <email address hidden>
tdf#122607 sw: restore CalcLayout() call in getRendererCount()
e8e60be...
by
Michael Stahl <email address hidden>
tdf#122607 sw: fix preservation of text frame cache entries
SwSaveSetLRUOfst would leave only 50 cache entries available for the
CalcLayout() to use; apparently it's not enough for this document.
The difference between the 1st loading/layout and the 3rd loading/layout
of the document is that in many paragraphs the cache entry is missing,
because the entires of the previous loads were clogging up the cache
and were preserved here, and the cache only has 50 available entries;
if enough entries are available, everything is positioned properly.
The idea with the 100 entries per visible shell actually comes from the
CVS initial import, where there was a comment suggesting that; but the
corresponding parameter was actually unused and removed in
7c704c78d3c652504c064b4ac7af55a2c1ee49bb.
Ideally we'd have time to investigate why a missing cache entry causes
the wrong position...
Reviewed-on: https://gerrit.libreoffice.org/71542
Tested-by: Jenkins
Reviewed-by: Michael Stahl <email address hidden>
(cherry picked from commit 3d37463eec0c891243a8971a34903b2da01c9e24)
Apparently nothing else would remove the entry, and without SwTextFrame
it's not accessible any more.
If the entry was recently used, then the SwSaveSetLRUOfst usage in
SwViewShell::CalcLayout() will preserve it instead of giving the cache
entry to a new frame.
Change-Id: Id43fdbad2ac006853928e30a7b6768c3e3dc1667
Reviewed-on: https://gerrit.libreoffice.org/71541
Tested-by: Jenkins
Reviewed-by: Michael Stahl <email address hidden>
(cherry picked from commit 31ae7509003b1e650463ee1468c0b315ba13efe6)
63fd178...
by
Thorsten Behrens <email address hidden>
Fix appearance for checkboxes
Conflicts:
vcl/source/gdi/pdfwriter_impl.cxx
(cherry picked from commit 49cb0dc7d70fdb12fa6eb91c98d63f9e0cf0067c)
