Commit d6544ee5 authored by barraclough@apple.com's avatar barraclough@apple.com

Source/JavaScriptCore: [GTK] Port scrollbar painting to GtkStyleContext

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
parent ed04bb96
......@@ -24,6 +24,31 @@
of hardcoding the GCC compiler.
* wtf/Platform.h: Define WTF_COMPILER_RVCT4_OR_GREATER if __ARMCC_VERSION >= 400000.
2011-01-06 Gavin Barraclough <barraclough@apple.com>
Reviewed by Geoff Garen.
Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
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.
* runtime/WeakGCMap.h:
(JSC::WeakGCMap::clear):
2011-01-06 Gavin Barraclough <barraclough@apple.com>
Reviewed by Darin Adler.
......
......@@ -49,6 +49,7 @@ public:
typedef typename HashMap<KeyType, MappedType>::const_iterator const_iterator;
bool isEmpty() { return m_map.isEmpty(); }
void clear() { m_map.clear(); }
MappedType get(const KeyType& key) const;
pair<iterator, bool> set(const KeyType&, const MappedType&);
......
2011-01-06 Gavin Barraclough <barraclough@apple.com>
Reviewed by Geoff Garen.
Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
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:
2011-01-07 Chris Marrin <cmarrin@apple.com>
Rubber-stamped by Simon Fraser.
......
......@@ -344,7 +344,7 @@ __ZN7WebCore14SecurityOrigin40setDomainRelaxationForbiddenForURLSchemeEbRKN3WTF6
__ZN7WebCore14SecurityOrigin6createERKN3WTF6StringES4_i
__ZN7WebCore14SecurityOrigin6createERKNS_4KURLEi
__ZN7WebCore15ArchiveResource6createEN3WTF10PassRefPtrINS_12SharedBufferEEERKNS_4KURLERKNS1_6StringESA_SA_RKNS_16ResourceResponseE
__ZN7WebCore15DOMWrapperWorld15unregisterWorldEv
__ZN7WebCore15DOMWrapperWorld13clearWrappersEv
__ZN7WebCore15DOMWrapperWorldD1Ev
__ZN7WebCore15DatabaseTracker12deleteOriginEPNS_14SecurityOriginE
__ZN7WebCore15DatabaseTracker14deleteDatabaseEPNS_14SecurityOriginERKN3WTF6StringE
......
......@@ -32,30 +32,14 @@ namespace WebCore {
DOMWrapperWorld::DOMWrapperWorld(JSC::JSGlobalData* globalData, bool isNormal)
: m_globalData(globalData)
, m_isNormal(isNormal)
, m_isRegistered(false)
{
registerWorld();
}
DOMWrapperWorld::~DOMWrapperWorld()
{
unregisterWorld();
}
void DOMWrapperWorld::registerWorld()
{
JSGlobalData::ClientData* clientData = m_globalData->clientData;
ASSERT(clientData);
static_cast<WebCoreJSClientData*>(clientData)->rememberWorld(this);
m_isRegistered = true;
}
void DOMWrapperWorld::unregisterWorld()
DOMWrapperWorld::~DOMWrapperWorld()
{
if (!m_isRegistered)
return;
m_isRegistered = false;
JSGlobalData::ClientData* clientData = m_globalData->clientData;
ASSERT(clientData);
static_cast<WebCoreJSClientData*>(clientData)->forgetWorld(this);
......@@ -68,6 +52,19 @@ void DOMWrapperWorld::unregisterWorld()
(*m_scriptControllersWithWindowShells.begin())->destroyWindowShell(this);
}
void DOMWrapperWorld::clearWrappers()
{
m_wrappers.clear();
m_stringCache.clear();
// These items are created lazily.
while (!m_documentsWithWrapperCaches.isEmpty())
(*m_documentsWithWrapperCaches.begin())->destroyWrapperCache(this);
while (!m_scriptControllersWithWindowShells.isEmpty())
(*m_scriptControllersWithWindowShells.begin())->destroyWindowShell(this);
}
DOMWrapperWorld* normalWorld(JSC::JSGlobalData& globalData)
{
JSGlobalData::ClientData* clientData = globalData.clientData;
......
......@@ -42,9 +42,9 @@ public:
return adoptRef(new DOMWrapperWorld(globalData, isNormal));
}
~DOMWrapperWorld();
void registerWorld();
void unregisterWorld();
// Free as much memory held onto by this world as possible.
void clearWrappers();
void didCreateWrapperCache(Document* document) { m_documentsWithWrapperCaches.add(document); }
void didDestroyWrapperCache(Document* document) { m_documentsWithWrapperCaches.remove(document); }
......@@ -66,7 +66,6 @@ private:
HashSet<Document*> m_documentsWithWrapperCaches;
HashSet<ScriptController*> m_scriptControllersWithWindowShells;
bool m_isNormal;
bool m_isRegistered;
};
DOMWrapperWorld* normalWorld(JSC::JSGlobalData&);
......
2011-01-06 Gavin Barraclough <barraclough@apple.com>
Reviewed by Geoff Garen.
Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
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]):
2011-01-04 Chris Fleizach <cfleizach@apple.com>
Reviewed by Sam Weinig.
......
......@@ -77,7 +77,7 @@ static WorldMap& allWorlds()
- (void)unregisterWorld
{
_private->world->unregisterWorld();
_private->world->clearWrappers();
}
- (void)dealloc
......
2011-01-06 Gavin Barraclough <barraclough@apple.com>
Reviewed by Geoff Garen.
Bug 52035 - Unregistering DOMWrapperWorlds is unsafe
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):
2011-01-07 Chris Marrin <cmarrin@apple.com>
Rubber-stamped by Simon Fraser.
......
......@@ -139,6 +139,6 @@ HRESULT WebScriptWorld::scriptWorldForGlobalContext(JSGlobalContextRef context,
HRESULT WebScriptWorld::unregisterWorld()
{
m_world->unregisterWorld();
m_world->clearWrappers();
return S_OK;
}
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment