[Libreoffice-commits] .: 2 commits - canvas/source sfx2/source

[Caolán McNamara]

 canvas/source/cairo/cairo_xlib_cairo.cxx |   20 +++++++++++++++++++-
 sfx2/source/doc/sfxbasemodel.cxx         |    3 +++
 2 files changed, 22 insertions(+), 1 deletion(-)

New commits:
commit a1d265be484f1c70f57ab3de9b2d8c27d2fd3aa4
Author: Caolán McNamara <caolanm at redhat.com>
Date:   Wed May 9 11:32:05 2012 +0100

    Resolves: rhbz#818557 crash with NULL shell post template update
    
    It's all a bit baffling in a maze of Shells, but what I can see is that
    when we update from the template at the end of loading we end up with
    a different order of shells on the stack than in the usual case.
    Apparently from positioning the cursor at an earlier stage than usual.
    
    If I lock the dispatcher for the duration of updating the template it all works
    out ok. I freely admit I can't foresee the full consequences of this, but it
    appears to work.
    
    Change-Id: Ib7b2f511cdb5a37715a6ad839d9b1426ad9db8e0

diff --git a/sfx2/source/doc/sfxbasemodel.cxx b/sfx2/source/doc/sfxbasemodel.cxx
index 02a4b9a..b3792d9 100644
--- a/sfx2/source/doc/sfxbasemodel.cxx
+++ b/sfx2/source/doc/sfxbasemodel.cxx
@@ -1198,7 +1198,10 @@ void SAL_CALL SfxBaseModel::connectController( const uno::Reference< frame::XCon
     {
         SfxViewFrame* pViewFrame = SfxViewFrame::Get( xController, GetObjectShell() );
         ENSURE_OR_THROW( pViewFrame, "SFX document without SFX view!?" );
+        bool bOldLock = pViewFrame->GetDispatcher()->IsLocked();
+        pViewFrame->GetDispatcher()->Lock(sal_True);
         pViewFrame->UpdateDocument_Impl();
+        pViewFrame->GetDispatcher()->Lock(bOldLock);
         const String sDocumentURL = GetObjectShell()->GetMedium()->GetName();
         if ( sDocumentURL.Len() )
             SFX_APP()->Broadcast( SfxStringHint( SID_OPENURL, sDocumentURL ) );
commit 107f8447818e50ba61221ca2ab0871347b7d6596
Author: Caolán McNamara <caolanm at redhat.com>
Date:   Wed May 9 09:17:42 2012 +0100

    Related: fdo#48961 don't crash on silly pixmap sizes
    
    Change-Id: I43dbe846160d19b203ad6bed06e807d4fbf7ce56

diff --git a/canvas/source/cairo/cairo_xlib_cairo.cxx b/canvas/source/cairo/cairo_xlib_cairo.cxx
index df14fce..0259154 100644
--- a/canvas/source/cairo/cairo_xlib_cairo.cxx
+++ b/canvas/source/cairo/cairo_xlib_cairo.cxx
@@ -40,6 +40,24 @@
 #include <vcl/virdev.hxx>
 #include <basegfx/vector/b2isize.hxx>
 
+namespace
+{
+    Pixmap limitXCreatePixmap(Display *display, Drawable d, unsigned int width, unsigned int height, unsigned int depth)
+    {
+        // The X protocol request CreatePixmap puts an upper bound
+        // of 16 bit to the size.
+        //
+        // see, e.g. moz#424333, fdo#48961
+        // we've a duplicate of this in vcl :-(
+        if (width > SAL_MAX_INT16 || height > SAL_MAX_INT16)
+        {
+            SAL_WARN("canvas", "overlarge pixmap: " << width << " x " << height);
+            return None;
+        }
+        return XCreatePixmap(display, d, width, height, depth);
+    }
+}
+
 namespace cairo
 {
 
@@ -232,7 +250,7 @@ namespace cairo
             }
 
             pFormat = XRenderFindStandardFormat( (Display*)maSysData.pDisplay, nFormat );
-            hPixmap = XCreatePixmap( (Display*)maSysData.pDisplay, maSysData.hDrawable,
+            hPixmap = limitXCreatePixmap( (Display*)maSysData.pDisplay, maSysData.hDrawable,
                                      width > 0 ? width : 1, height > 0 ? height : 1,
                                      pFormat->depth );