[Libreoffice-commits] core.git: 2 commits - sw/source

Michael Stahl mstahl at redhat.com
Fri Apr 21 22:12:01 UTC 2017


 sw/source/core/access/accmap.cxx   |    5 ++++-
 sw/source/core/layout/calcmove.cxx |    6 ++++++
 2 files changed, 10 insertions(+), 1 deletion(-)

New commits:
commit c99f72bebdce6d294eb47e070fa1397a98ba2087
Author: Michael Stahl <mstahl at redhat.com>
Date:   Fri Apr 21 23:50:23 2017 +0200

    sw: fix a11y crash on double Dispose
    
    When testing with the bugdoc for tdf#107126, it happend that upon
    applying a page style, SwAccessibleContext::Dispose() was called twice,
    and that's not supposed to happen (and crashes, too, at least inside
    an assertion).
    
    There was an Action that queued up a bunch of events, but the Action did
    not complete formatting the document, so right after that during Paint
    more formatting happened and then the FireEvents() called Dispose()
    and InvalidatePosOrSize() called it again.  Guess we shouldn't generate
    events for objects that we know are disposed due to not being visible.
    
    Change-Id: I5a0f04c0f32ee5e949b552f7a373c10ceee5c279

diff --git a/sw/source/core/access/accmap.cxx b/sw/source/core/access/accmap.cxx
index 0e3d01b66f45..bf530abb7349 100644
--- a/sw/source/core/access/accmap.cxx
+++ b/sw/source/core/access/accmap.cxx
@@ -2390,7 +2390,10 @@ void SwAccessibleMap::InvalidatePosOrSize( const SwFrame *pFrame,
             else
             {
                 FireEvents();
-                xAccImpl->InvalidatePosOrSize( rOldBox );
+                if (xAccImpl->GetMap()) // not if disposed by FireEvents()
+                {
+                    xAccImpl->InvalidatePosOrSize(rOldBox);
+                }
             }
         }
         else if( xParentAccImpl.is() )
commit 4d43f9e9dda5edeeb6e4b99487b5b6a1fae4bd56
Author: Michael Stahl <mstahl at redhat.com>
Date:   Fri Apr 21 22:44:14 2017 +0200

    tdf#107126 sw: fix layout crash with section in footnote
    
    SwContentFrame::WouldFit_() contains a hack to temporarily reparent a
    SwTextFrame.  In the bugdoc, there is a SwTextFrame below a
    SwSectionFrame below a SwFootnoteFrame.  The reparenting ignores the
    SwSectionFrame so the result is a SwTextFrame below SwFootnoteFrame, but
    it still has its mbInfSct set, hence crashes with a null pointer.
    
    If the SwTextFrame is permanently moved later on, in
    SwFlowFrame::MoveBwd() line 2450 a new SwSectionFrame is created.
    
    Change-Id: I45a7ab793b4459e551bd11b7fb83dedc58a6c8da

diff --git a/sw/source/core/layout/calcmove.cxx b/sw/source/core/layout/calcmove.cxx
index 26eda5e3fef2..65fab03a33c8 100644
--- a/sw/source/core/layout/calcmove.cxx
+++ b/sw/source/core/layout/calcmove.cxx
@@ -1868,6 +1868,11 @@ bool SwContentFrame::WouldFit_( SwTwips nSpace,
             SwFrame *pOldNext = pTmpFrame->GetNext();
             pTmpFrame->RemoveFromLayout();
             pTmpFrame->InsertBefore( pNewUpper, nullptr );
+            // tdf#107126 for a section in a footnote, we have only inserted
+            // the SwTextFrame but no SwSectionFrame - reset mbInfSct flag
+            // to avoid crashing (but perhaps we should create a temp
+            // SwSectionFrame here because WidowsAndOrphans checks for that?)
+            pTmpFrame->InvalidateInfFlags();
             if ( pFrame->IsTextFrame() &&
                  ( bTstMove ||
                    static_cast<SwTextFrame*>(pFrame)->HasFollow() ||
@@ -1885,6 +1890,7 @@ bool SwContentFrame::WouldFit_( SwTwips nSpace,
 
             pTmpFrame->RemoveFromLayout();
             pTmpFrame->InsertBefore( pUp, pOldNext );
+            pTmpFrame->InvalidateInfFlags(); // restore flags
         }
         else
         {


More information about the Libreoffice-commits mailing list