summaryrefslogtreecommitdiff
path: root/sw
AgeCommit message (Collapse)Author
2017-07-01tdf#108448 ww8export: endnote unit testJustin Luth
Change-Id: I3559e51c7fe9fedf616857b5ae612b4a8f6c67d5 Reviewed-on: https://gerrit.libreoffice.org/39431 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-07-01tdf#108448 ww8export: skip sectionbreak for endnotesJustin Luth
MSWord ignores page-breaks in endnotes, and just adds endnotes at the end of the last page. LO automatically page-breaks with pageStyle Endnotes. It must be built into the code that handles endnotes. Don't try to export that page-break - it doesn't work anyway. Change-Id: I2f266b20a6fa97d0522878f71fe0a6822833d89c Reviewed-on: https://gerrit.libreoffice.org/38727 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-07-01sw:findtext - remove useless nStart = nProxyStartJustin Luth
...since the clause is immediately followed by nStart = nEnd. Change-Id: I306f6012b4e8f69288d3470214853c17546906e7 Reviewed-on: https://gerrit.libreoffice.org/39359 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-06-29related tdf#82173 writerfilter: ensure Xnote para-style round-trippingJustin Luth
MSO Xnote styles are "footnote text"/"endnote text". LO Xnote styles are "Footnote"/"Endnote", and exports Footnote as "Footnote Text" and Endnote as "Endnote Text" The mapping ensures that the same Xnote style applies to both existing (loaded) notes, as well as newly inserted notes. This patch does two things: 1.) Endnote should not translate into Endnote Symbol. 2.) Prepare for when style mapping becomes case sensitive again Change-Id: I9881c069a3124f83cd0bc2a428577c4a382a8377 Reviewed-on: https://gerrit.libreoffice.org/39395 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-06-29tdf#108836 sw: don't enable Undo if Steps configured to 0Michael Stahl
It doesn't work. Change-Id: Iafc3eb50f481faffee60592aa3b6fd2ed4387b90
2017-06-29improve refcounting lopluginNoel Grandin
to find ref-counted classes being managed via other smart pointer classes. Hopefully prevent needing fixes like 642ae256ea5b8083ba0b3c097ca8ea52304b9cdb "ChangedUIEventListener is refcounted, mustn't be helt by unique_ptr" Change-Id: I6b0c5f8f87ce3546a8a1104ce1000470c09459bd Reviewed-on: https://gerrit.libreoffice.org/39378 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-28Watermark: tdf#91687 correct size in the .docSzymon Kłos
Export: * Watermarks saved using Writer were very small in the MSO. Export fUsegtextFStretch property in the Geometry Text Boolean Properties. * tdf#91687: SnapRect contains size of Watermark after rotation. We have to export size without rotation. Import: * When import set height depending on used font and width. Text will keep the ratio. Remember the padding for export. * added unit test * introduced enum to avoid magic numbers for stretch and best fit properties. Change-Id: I3427afe78488d499f13c543ca401c096161aaf34 Reviewed-on: https://gerrit.libreoffice.org/38979 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2017-06-28SvXMLEmbeddedObjectHelper::Create bDirect parameter is unusedStephan Bergmann
...ever since 63d13cb2ee2c4725599714f6184bcd6e77a1eab7 "#87246#: OLE object support through SAX interface" Change-Id: Ib1d63a3a6adf64e2b5d3a16df5a7c6473d46abfb Reviewed-on: https://gerrit.libreoffice.org/39364 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-06-28sw lok: rename return values UNDO_CONFLICT to SID_REPAIRPACKAGEHenry Castro
To be consistent with sc, sd and sw Change-Id: I273101de6e59be08eb61b1a77647bc1dd26ff387 Reviewed-on: https://gerrit.libreoffice.org/39369 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Henry Castro <hcastro@collabora.com>
2017-06-28sw:findtxt - whitespace cleanupJustin Luth
Change-Id: I4294617a1cc6cf123dd4bb8efd8c233ba782fdfe Reviewed-on: https://gerrit.libreoffice.org/39360 Reviewed-by: Justin Luth <justin_luth@sil.org> Tested-by: Justin Luth <justin_luth@sil.org>
2017-06-28tdf#108826 sw: also handle RES_REMOVE_UNO_OBJECT in SwCallMouseEventMichael Stahl
This is sent from SwUndoFlyBase::DelFly(); the SwFrameFormat isn't deleted in this case but it's no longer part of the document, so an UI class like SwCallMouseEvent should stop pointing to it. Change-Id: I05349271d14bb1948ea30528cd85c68ed638f28e
2017-06-28remove default-able copy ctors and copy operatorsJochen Nitschke
The implicit defined ctors and operators will copy all members (and bases). Since C++11 implicit copy is depreciated if there is a non-default dtor, keep such copies. This commit includes only types that had either copy ctor or copy operator and were found by cppcheck. Change-Id: I93ee687fb3b3c5884f475a2c6054955cdde57ed7 Reviewed-on: https://gerrit.libreoffice.org/39351 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-28-Werror=ignored-qualifiers (GCC 8)Stephan Bergmann
Change-Id: Icc576de378c27764aa50457f8d548564eb4a3aec
2017-06-28-Werror=catch-value= (GCC 8)Stephan Bergmann
Change-Id: I63c264a39bcec5ebd80c73acb55c72713fd706e2
2017-06-28tdf#108714 follow-up: handle deferred break in character groupMike Kaganski
If an out-of-order break happens immediately after a table, then in following paragraph group (before character group start) the table level is > 0, and break is ignored. Since out-of-order break only happens at top level, the following character group necessarily designates a new paragraph group, so it's OK to handle that at the character group level, where table level is already updated. Change-Id: Ic1b1bb89e12407b050c2e880ad971794311845a5 Reviewed-on: https://gerrit.libreoffice.org/39347 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-06-28tdf#107880: Make use of ScopedVclPtrChristian Barth
Make the use of VclPtr<VirtualDevice> exception safe by using ScopedVclPtr<VirtualDevice> when disposeAndClear() is called in same method. Change-Id: I684eb7fb92c2bf16c30e74dce8e691dfca1a1f45 Signed-off-by: Christian Barth <Christian.Barth@zoho.com> Reviewed-on: https://gerrit.libreoffice.org/39321 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-28use std::vector in BigPtrArrayNoel Grandin
Change-Id: Ibf63213eb44ef2bb51042607cbdedcb66181b51a Reviewed-on: https://gerrit.libreoffice.org/39302 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-27tdf#108714: allow <w:br> as direct child of <w:body>Mike Kaganski
LibreOffice doesn't accept <w:br> element as a child of <w:body>. ECMA-376-1:2016 17.3.3.1 describes br as element of a run content, and points to CT_Br in §A.1. CT_Br may appear only as part of EG_RunInnerContent. In turn, EG_RunInnerContent may appear only inside CT_R. So, using <w:br> outside of <w:r> produces ill-formed OOXML. Open XML SDK 2.5 Productivity Tool for Microsoft Office confirms that, showing OpenXmlUnknownElement error. However, Word accepts it as direct child of <w:body>. It behaves as if the <w:br> were used as first element in first run of the following <w:p> (thus creating page break after next paragraph). Another Word bug that provokes third-parties to create ill-formed documents, and requires LibreOffice to be bug-to-bug compatible. This commit makes the following changes: 1. Registers a dedicated complex type CT_Br_OutOfOrder to handle those unusual breaks, with corresponding handler function. 2. In the handler function, saves the gathered property set to parser state to use later in next paragraph group handler. This reproduces Word behaviour. Change-Id: I5df6927e2de9266b58f87807319ad1c4977e45a7 Reviewed-on: https://gerrit.libreoffice.org/39168 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-06-27tdf#100075 DOCX frame height rule updatedVasily Melenchuk
According to "[MS-OE376]: Office Implementation Information for ECMA-376 Standards Support" Word treats default value for hRule attribute in a different way: if frame height is missing it is "auto" (as in specification), but if frame height exist, then default value for hRule is "atLeast". Change-Id: I0ce30b61d1a6b85febbbd8a6bf5af3eb1bb2767f Reviewed-on: https://gerrit.libreoffice.org/39065 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
2017-06-27use std::array in BlockInfoNoel Grandin
Change-Id: I28a13592e5993454ae96b0a32ba328013da7856e Reviewed-on: https://gerrit.libreoffice.org/39296 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-27loplugin:oncevar in swNoel Grandin
Change-Id: Ia96172489eec09607113d388a5b683bb6e0d2dec Reviewed-on: https://gerrit.libreoffice.org/39290 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-27inline ElementPtrNoel Grandin
Change-Id: I93a9527283a819a95563565a252a5088253c91c0 Reviewed-on: https://gerrit.libreoffice.org/39293 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-27sw: fix the assertion in SwModule::Notify()Michael Stahl
This assertion (for i#116192) is actually triggered while loading fdo65932.html in CppunitTest_sw_filters_test: The perverted LoadHiddenDocument() hack in SwHTMLParser::SetControlSize() may create a view too early, before loading finishes, but this shouldn't be a problem because HTML is never a template, so move the assertion into the place where we actually modify the document directly without going via the shell. Change-Id: Ifa4b1ec4ab4142f4159daf5785cd90b5468f7e3e
2017-06-27fdo#43157 convert OSL_ASSERT to assert in sw/sourceBernhard Widl
Change-Id: Ibef2f8deb36e2123f22bd925d1360c34de0ce47b Reviewed-on: https://gerrit.libreoffice.org/39270 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-06-27tdf#108806: convert CRLF into space in OOXML textMike Kaganski
Change-Id: I8e2e108a705ecdb55c096a589d83d51c48b0b83c Reviewed-on: https://gerrit.libreoffice.org/39286 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-06-26Avoid loplugin:unreffunStephan Bergmann
...after 272d5a02a3de2350f8af7a93281b651316b24ae5 "Revert 'tdf#108524 sw: attempt to split section frames inside table cells'" Change-Id: Ic1ec8cd3284e2ba98630552c80d99b5d67fc7efd
2017-06-26Revert "tdf#108524 sw: attempt to split section frames inside table cells"Michael Stahl
This reverts commit f991b842addddeada6dc45c4054deeca5aa7f17b. It doesn't really work and crashes on ooo61225-1.sxw in 1 in SwFrame::FindTabFrame() (this=0x0) at sw/source/core/inc/frame.hxx:913 2 in SwFrame::GetNextSctLeaf(MakePageType) (this=0x3137130, eMakePage=MAKEPAGE_INSERT) at sw/source/core/layout/sectfrm.cxx:1529 3 in SwFrame::GetLeaf(MakePageType, bool) (this=0x3137130, eMakePage=MAKEPAGE_INSERT, bFwd=true) at sw/source/core/layout/flowfrm.cxx:805 4 in SwFlowFrame::MoveFwd(bool, bool, bool) (this=0x31371d8, bMakePage=true, bPageBreak=false, bMoveAlways=false) at sw/source/core/layout/flowfrm.cxx:1861 The code added in GetNextSctLeaf() looks unfinished to me: it assumes that something else has added a follow-frame for the SwCellFrame containing the SwSectionFrame already, but AFAICT the GetNextSctLeaf() function is responsible for creating that SwCellFrame follow. The caller (in GetLeaf()) specifically checks for this condition and avoids calling GetNextCellLeaf(). Change-Id: I51875830771f07f5d2fec293f6063c73fc68d468
2017-06-26Revert "crashtesting failure on ooo61225-1.sxw"Michael Stahl
This reverts commit 55d4cc340068b0f590ab3a2119a2a2a71a3f8e5e. It's obviously bogus to have mbInfTab set but ImplFindTabFrame return null. Also, just loading the document still crashes with the same problem in a different place.
2017-06-26fdo#43157 convert OSL_ASSERT to assert in sw/source/coreBernhard Widl
Change-Id: I6ffd9832ff1085c84fde8763045f3d1cb02137e2 Reviewed-on: https://gerrit.libreoffice.org/38974 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-06-26use implicit default copy assignmentJochen Nitschke
I guess Coverity complained that there was a copy assignment operator but no copy ctor, move assignment and move ctor defined. Change-Id: I10641c9f403e609406b2a1420b22abbfc9dbc6fc Reviewed-on: https://gerrit.libreoffice.org/39240 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-06-26Fix typosAndrea Gelmini
Change-Id: I2ce725f87ee6f8ebcffbac268cc7e7f8850023e5 Reviewed-on: https://gerrit.libreoffice.org/39232 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2017-06-26s/catched/caughtNoel Grandin
Change-Id: I7ea6977a9749e86f8058b78cdb91cd2c62da8264 Reviewed-on: https://gerrit.libreoffice.org/39164 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-25crashtesting failure on ooo61225-1.sxwCaolán McNamara
Change-Id: Ia953443ba352aea1b33b6efd312a0e95a6b8918e Reviewed-on: https://gerrit.libreoffice.org/39244 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-06-24Set OK as default button in MM Assign Fields dialogGabor Kelemen
Shut this warning up: warn:vcl.layout:28925:1:vcl/source/window/builder.cxx:519: No default button defined in modules/swriter/ui/assignfieldsdialog.ui Change-Id: Ide113c694ac6cf20361a81ed53c474494f172921 Reviewed-on: https://gerrit.libreoffice.org/39190 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
2017-06-24tdf#98800 Enable Next button on the third page of the MM WizardGabor Kelemen
This seems to enable and disable the Next button even if the 'This page shall' checkbox is already enabled after a previous run. Change-Id: I9cba7649b9cd1df110c5a120d4eea3d97b3afcf1 Reviewed-on: https://gerrit.libreoffice.org/38553 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
2017-06-24update notebookbar_groupedbar_fullandreas kainz
Change-Id: I467388a8f67cc331f3babadd44bc5d720997a63e Reviewed-on: https://gerrit.libreoffice.org/38260 Reviewed-by: Yousuf Philips <philipz85@hotmail.com> Tested-by: Yousuf Philips <philipz85@hotmail.com>
2017-06-23iOS, convert CPPUnittest to noopjan Iversen
unittest is not supported for iOS due to the way it is build Change-Id: I0682c5252231668edc2ec186147b872ef6fcc695
2017-06-23simplify some string handling in tracing callsNoel Grandin
Change-Id: I0fb76562429e691400a02216019c7f96791cf9b3 Reviewed-on: https://gerrit.libreoffice.org/39159 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-06-23sw: fix UBSAN error in CppunitTest_sw_odfimportMichael Stahl
/sw/source/core/layout/calcmove.cxx:1686:43: runtime error: downcast of address 0x2ae9ba4566c0 which does not point to an object of type 'const SwFootnoteFrame' 0x2ae9ba4566c0: note: object is of type 'SwSectionFrame' Footnotes can contain sections of course, so use FindFootnoteFrame(). (regression from c83a443eb106e426901d0ba8a809eedcd24c42c5) Change-Id: I7824c81ba74ed3341f0ba5b14dac89d71f6318db Reviewed-on: https://gerrit.libreoffice.org/39157 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins <ci@libreoffice.org>
2017-06-23Fix typosAndrea Gelmini
Change-Id: I1348be80d3150966124a7f62134ecf3df01c659e Reviewed-on: https://gerrit.libreoffice.org/39158 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2017-06-23coverity#1412991 Resource leakCaolán McNamara
Change-Id: I0fc9b64ba8783530a0b7d597edbf8be8a43f5fd6
2017-06-23Fix typos: uniform registeredAndrea Gelmini
We have in the same files "registered" and "registred". Change-Id: I604a8fdb7d5c40fe208fc11e9120333b3eaef3da Reviewed-on: https://gerrit.libreoffice.org/39097 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2017-06-23writerfilter: map endnote text to EndnoteJustin Luth
I'm not exactly sure what role the Endnote Symbol char style plays, but it is only related to Endnote Characters, not the main footnote text. Note: the existing mapping rarely takes effect since MSWord exports the stylename in lower-case. Unfortunately, there is no history to indicate why "Endnote Text" is mapped to "Endnote Symbol". That looks like an error to me. related to tdf#82173 which exposed this issue. Change-Id: Ie92f527b1e594fd571f1118d18a8ff225cfc2314 Reviewed-on: https://gerrit.libreoffice.org/38605 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2017-06-22tdf#108682 DOCX import: fix <w:spacing w:line=...> for negative valuesMiklos Vajna
I didn't find UI in Word to create <w:spacing w:line="-260" w:lineRule="auto"/> the equivalent markup when you set line spacing to exactly 13pt for new documents is: <w:spacing w:line="260" w:lineRule="exact"/> The OOXML spec and Microsoft's implementer notes ([MS-OI29500]) is also pretty silent about what a negative value means. However, if this markup is converted to WW8 by Word, then the WW8 LPSD structure is like this (as presented by doc-dumper): <lspd type="LSPD" offset="5086"> <dyaLine value="0xfefc"/> <fMultLinespace value="0x1"/> </lspd> For the 0xfefc value the [MS-DOC] spec clearly states that means the type of the spacing is "exactly", with the value of 0x10000-0xfefc, i.e. the same 260 twips. Change-Id: I84b485d02dea49c610b6df2e06ccce03e1d29d21 Reviewed-on: https://gerrit.libreoffice.org/39091 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-06-22tdf#101821 sw: fix layout footnote use-after-free in SwRootFrameMichael Stahl
The ClearSwLayouterEntries() accesses anchored objects and if they are anchored in footnotes then RemoveFootnotes() has already deleted them. (regression from 962d0500c4debaef43e5f146e47e08c66d851562) Invalid write of size 1 at 0x4143CCB3: SwAnchoredObject::SetTmpConsiderWrapInfluence(bool) (anchoredobject.cxx:739) by 0x414D8A21: SwObjsMarkedAsTmpConsiderWrapInfluence::Clear() (objstmpconsiderwrapinfl.cxx:58) by 0x414C943E: SwLayouter::ClearObjsTmpConsiderWrapInfluence(SwDoc const&) (layouter.cxx:401) by 0x411DBE57: sw::DocumentLayoutManager::ClearSwLayouterEntries() (DocumentLayoutManager.cxx:504) by 0x414D05D9: SwRootFrame::DestroyImpl() (newfrm.cxx:594) by 0x41535AB3: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:389) by 0x419E8171: std::_Sp_counted_deleter<SwRootFrame*, void (*)(SwFrame*), std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (shared_ptr_base.h:464) by 0x40EB6DB5: std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (shared_ptr_base.h:150) by 0x40EB5E76: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (shared_ptr_base.h:662) by 0x419E65F9: std::__shared_ptr<SwRootFrame, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() (shared_ptr_base.h:928) by 0x419E6615: std::shared_ptr<SwRootFrame>::~shared_ptr() (shared_ptr.h:93) by 0x419E619D: SwViewShell::~SwViewShell() (vnew.cxx:285) Address 0x5feb6eee is 334 bytes inside a block of size 488 free'd at 0x4C2F21A: operator delete(void*) (vg_replace_malloc.c:576) by 0x41488962: SwFlyAtContentFrame::~SwFlyAtContentFrame() (flyfrms.hxx:134) by 0x41535AFC: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:391) by 0x415360BD: SwLayoutFrame::DestroyImpl() (ssfrm.cxx:477) by 0x41535AB3: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:389) by 0x414A2FF4: sw_RemoveFootnotes(SwFootnoteBossFrame*, bool, bool) (ftnfrm.cxx:852) by 0x414A3104: sw_RemoveFootnotes(SwFootnoteBossFrame*, bool, bool) (ftnfrm.cxx:874) by 0x414A321A: SwRootFrame::RemoveFootnotes(SwPageFrame*, bool, bool) (ftnfrm.cxx:897) by 0x414D0558: SwRootFrame::DestroyImpl() (newfrm.cxx:585) by 0x41535AB3: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:389) by 0x419E8171: std::_Sp_counted_deleter<SwRootFrame*, void (*)(SwFrame*), std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (shared_ptr_base.h:464) by 0x40EB6DB5: std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (shared_ptr_base.h:150) by 0x40EB5E76: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (shared_ptr_base.h:662) by 0x419E65F9: std::__shared_ptr<SwRootFrame, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() (shared_ptr_base.h:928) by 0x419E6615: std::shared_ptr<SwRootFrame>::~shared_ptr() (shared_ptr.h:93) by 0x419E619D: SwViewShell::~SwViewShell() (vnew.cxx:285) Change-Id: I147f46d49c90de46189ad34feed66c289adddc15
2017-06-22tdf#39468 Translate some random German comments/termsJens Carl
Change-Id: I38cb79abb2a495ccca454903bc46b407009e8290 Reviewed-on: https://gerrit.libreoffice.org/39084 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2017-06-22sw: dump more connections of those obnoxious footnotes in layout.xmlMichael Stahl
Change-Id: I62caffcacb710aa079ddc9c81fb49f702cdc84af
2017-06-22tdf#101821 sw: fix another layout footnote use-after-freeMichael Stahl
In SwContentFrame::MakeAll() the pPre (previous frame) is deleted in a call to MoveFwd(). This SwTextFrame is inside of a footnote, and the SwFlowFrame::CutTree() for whatever reason wants to format all of the SwTextFrames inside the same SwFootnoteFrame, which causes the pPre to be joined with another one. Let's try to avoid that by checking that it's still in the layout after the call to MoveFwd(); on the one hand it's not obvious that this frame is important enough that it should be kept alive with ForbidDelete(), on the other hand i have no idea if simply removing the ValidateSz() call would introduce new loops or whatever. Invalid read of size 4 at 0x414E8D14: SwFrame::IsSctFrame() const (frame.hxx:1018) by 0x41A85A29: SwContentFrame::MakeAll(OutputDevice*) (calcmove.cxx:1713) by 0x41A7F499: SwFrame::OptPrepareMake() (calcmove.cxx:368) by 0x41ADF0CF: SwFrame::OptCalc() const (frame.hxx:892) by 0x41ADCC07: SwLayAction::FormatContent_(SwContentFrame const*, SwPageFrame const*) (layact.cxx:1789) by 0x41ADC195: SwLayAction::FormatContent(SwPageFrame const*) (layact.cxx:1620) 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 0x530ccf80 is 160 bytes inside a block of size 264 free'd at 0x4C2ED4A: free (vg_replace_malloc.c:530) by 0x4E5BCD0: rtl_freeMemory_SYSTEM(void*) (alloc_global.cxx:271) by 0x4E5C00A: rtl_freeMemory (alloc_global.cxx:341) by 0x4E5AAA0: rtl_cache_free (alloc_cache.cxx:1231) by 0xEFC9A6F: FixedMemPool::Free(void*) (mempool.cxx:49) by 0x41CA7DFA: SwTextFrame::operator delete(void*, unsigned long) (txtfrm.hxx:377) by 0x41C9F7B6: SwTextFrame::~SwTextFrame() (txtfrm.cxx:415) by 0x41B5B74C: SwFrame::DestroyFrame(SwFrame*) (ssfrm.cxx:391) by 0x41C1589A: SwTextFrame::JoinFrame() (frmform.cxx:656) by 0x41C153B1: SwTextFrame::AdjustFollow_(SwTextFormatter&, int, int, unsigned char) (frmform.cxx:555) by 0x41C172E1: SwTextFrame::FormatAdjust(SwTextFormatter&, WidowsAndOrphans&, int, bool) (frmform.cxx:1108) by 0x41C18D5E: SwTextFrame::Format_(SwTextFormatter&, SwTextFormatInfo&, bool) (frmform.cxx:1550) by 0x41C19340: SwTextFrame::Format_(OutputDevice*, SwParaPortion*) (frmform.cxx:1660) by 0x41C19CD8: SwTextFrame::Format(OutputDevice*, SwBorderAttrs const*) (frmform.cxx:1807) by 0x41A847A1: SwContentFrame::MakeAll(OutputDevice*) (calcmove.cxx:1393) by 0x41A7F211: SwFrame::PrepareMake(OutputDevice*) (calcmove.cxx:346) by 0x41B75758: SwFrame::Calc(OutputDevice*) const (trvlfrm.cxx:1761) by 0x41A973E7: SwFlowFrame::CutTree(SwFrame*) (flowfrm.cxx:424) 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 0x41A7F499: SwFrame::OptPrepareMake() (calcmove.cxx:368) by 0x41ADF0CF: SwFrame::OptCalc() const (frame.hxx:892) by 0x41ADCC07: SwLayAction::FormatContent_(SwContentFrame const*, SwPageFrame const*) (layact.cxx:1789) by 0x41ADC195: SwLayAction::FormatContent(SwPageFrame const*) (layact.cxx:1620) 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: I35b27a32608d4dcf98e0933cce76ce5ddb1c09d9
2017-06-22tdf#101821 sw: fix layout footnote use-after-freeMichael Stahl
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
2017-06-22tdf#101821 sw: layout: don't move endnotes into footnotes' containerMichael Stahl
The bugdoc has a single 1-column section from start to end, no footnotes but lots of endnotes, and the section has the settings "Footnotes - collect at end of text" unchecked and "Endnotes - collect at end of section" checked. This means that the SwFootnoteContFrame for footnotes would be put directly below the SwPageFrame (so that multiple sections on a single page can share it), but the SwFootnoteContFrame for the endnotes is put below the SwColumnFrame (which is created despite only 1 column) below the SwSectionFrame. Hence content in endnotes has the mbInfSct flag set, and the crash happens because the endnotes are moved from below the SwSectionFrame to a new SwFootnoteContFrame that is directly below a SwPageFrame, without clearing the mbInfSct flag. Fix the wrong call in SwFootnoteBossFrame::MoveFootnotes_() to FindFootnoteBossFrame() that resulted in the wrong (unsuitable for endnotes) SwFootnoteContFrame to be used as the target for the move. Change-Id: I64f6b86441e5ac1f16433f005e97c274a1c69dfa
generated by cgit (git 2.34.1) at 2025-02-07 08:44:32 +0000