Skip to content
  • barraclough@apple.com's avatar
    Source/JavaScriptCore: [GTK] Port scrollbar painting to GtkStyleContext · d6544ee5
    barraclough@apple.com authored
    https://bugs.webkit.org/show_bug.cgi?id=52051
    
    Patch by Carlos Garcia Campos <cgarcia@igalia.com> on 2011-01-07
    Reviewed by Martin Robinson.
    
    * wtf/gobject/GTypedefs.h: Add GtkStyleContext forward
    declaration.
    
    WebCore: Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
    
    Reviewed by Geoff Garen.
    
    The method DOMWrapperWorld::unregisterWorld() effectively calls the DOMWrapperWorld's
    destructor early, in order to release wrappers once we know we no longer intend to use them.
    Whilst it is okay to have a method to throw away wrappers (assuming we know we're willing to
    lose any state stored on them) it is not okay to deregister the world from the JSGlobalData.
    A sequence of events that triggers the bug would look like this:
    
    (1) Create a DOMWrapperWorld.
    (2) Register a timer in the world.
    (3) Call unregisterWorld() on the world.
    (4) Timer goes off, code is executed in the world, creates a Node not attached to a Document.
    (5) We attempt to lookup a wrapper map for the world on the JSGlobalData, but because we've
        called forgetWorld() none exists.
    (6) Attempt to add a wrapper to a NULL map.
    
    Fix the problem by not removing the JSGlobalData's wrapper map until the world really goes away.
    
    * WebCore.exp.in:
    * bindings/js/DOMWrapperWorld.cpp:
    (WebCore::DOMWrapperWorld::DOMWrapperWorld):
    (WebCore::DOMWrapperWorld::~DOMWrapperWorld):
    (WebCore::DOMWrapperWorld::clearWrappers):
    * bindings/js/DOMWrapperWorld.h:
    
    WebKit/mac: Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
    
    Reviewed by Geoff Garen.
    
    The method DOMWrapperWorld::unregisterWorld() effectively calls the DOMWrapperWorld's
    destructor early, in order to release wrappers once we know we no longer intend to use them.
    Whilst it is okay to have a method to throw away wrappers (assuming we know we're willing to
    lose any state stored on them) it is not okay to deregister the world from the JSGlobalData.
    A sequence of events that triggers the bug would look like this:
    
    (1) Create a DOMWrapperWorld.
    (2) Register a timer in the world.
    (3) Call unregisterWorld() on the world.
    (4) Timer goes off, code is executed in the world, creates a Node not attached to a Document.
    (5) We attempt to lookup a wrapper map for the world on the JSGlobalData, but because we've
        called forgetWorld() none exists.
    (6) Attempt to add a wrapper to a NULL map.
    
    Fix the problem by not removing the JSGlobalData's wrapper map until the world really goes away.
    
    * WebView/WebScriptWorld.mm:
    (-[WebScriptWorld unregisterWorld]):
    
    WebKit/win: Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
    
    Reviewed by Geoff Garen.
    
    The method DOMWrapperWorld::unregisterWorld() effectively calls the DOMWrapperWorld's
    destructor early, in order to release wrappers once we know we no longer intend to use them.
    Whilst it is okay to have a method to throw away wrappers (assuming we know we're willing to
    lose any state stored on them) it is not okay to deregister the world from the JSGlobalData.
    A sequence of events that triggers the bug would look like this:
    
    (1) Create a DOMWrapperWorld.
    (2) Register a timer in the world.
    (3) Call unregisterWorld() on the world.
    (4) Timer goes off, code is executed in the world, creates a Node not attached to a Document.
    (5) We attempt to lookup a wrapper map for the world on the JSGlobalData, but because we've
        called forgetWorld() none exists.
    (6) Attempt to add a wrapper to a NULL map.
    
    Fix the problem by not removing the JSGlobalData's wrapper map until the world really goes away.
    
    * WebScriptWorld.cpp:
    (WebScriptWorld::unregisterWorld):
    
    
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75265 268f45cc-cd09-0410-ab3c-d52691b4dbfc
    d6544ee5