[SCM] WebKit Debian packaging branch, debian/experimental, updated. upstream/1.3.3-10851-g50815da

[andersca at apple.com]

The following commit has been merged in the debian/experimental branch:
commit 5dd07203db36a507c767524323f77cde17e767b5
Author: andersca at apple.com <andersca at apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date:   Tue Dec 7 00:57:32 2010 +0000

    WebProcess crash in NPRemoteObjectMap::invalidate when closing tab
    https://bugs.webkit.org/show_bug.cgi?id=50597
    <rdar://problem/8655584>
    
    Reviewed by Sam Weinig.
    
    When invalidating the NPRemoteObjectMap, we don't want NPObjectMessageReceiver to
    release all objects NPObjects blindly because NPJSObjects have already been deallocated by the plug-in view.
    
    This is not an ideal solution; an ideal solution would involve NPJSObjects notifying any NPObjectMessageReceiver objects
    that the NPJSObject is being destroyed. The NPObjectMessageReceiver could then simply null out the NPObject pointer.
    
    * Shared/Plugins/NPObjectMessageReceiver.cpp:
    (WebKit::NPObjectMessageReceiver::NPObjectMessageReceiver):
    (WebKit::NPObjectMessageReceiver::~NPObjectMessageReceiver):
    * Shared/Plugins/NPObjectMessageReceiver.h:
    * Shared/Plugins/NPRemoteObjectMap.cpp:
    (WebKit::NPRemoteObjectMap::NPRemoteObjectMap):
    (WebKit::NPRemoteObjectMap::invalidate):
    * Shared/Plugins/NPRemoteObjectMap.h:
    (WebKit::NPRemoteObjectMap::isInvalidating):
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@73414 268f45cc-cd09-0410-ab3c-d52691b4dbfc

diff --git a/WebKit2/ChangeLog b/WebKit2/ChangeLog
index 0dfaf55..19a849b 100644
--- a/WebKit2/ChangeLog
+++ b/WebKit2/ChangeLog
@@ -1,3 +1,27 @@
+2010-12-06  Anders Carlsson  <andersca at apple.com>
+
+        Reviewed by Sam Weinig.
+
+        WebProcess crash in NPRemoteObjectMap::invalidate when closing tab
+        https://bugs.webkit.org/show_bug.cgi?id=50597
+        <rdar://problem/8655584>
+
+        When invalidating the NPRemoteObjectMap, we don't want NPObjectMessageReceiver to
+        release all objects NPObjects blindly because NPJSObjects have already been deallocated by the plug-in view.
+
+        This is not an ideal solution; an ideal solution would involve NPJSObjects notifying any NPObjectMessageReceiver objects
+        that the NPJSObject is being destroyed. The NPObjectMessageReceiver could then simply null out the NPObject pointer.
+
+        * Shared/Plugins/NPObjectMessageReceiver.cpp:
+        (WebKit::NPObjectMessageReceiver::NPObjectMessageReceiver):
+        (WebKit::NPObjectMessageReceiver::~NPObjectMessageReceiver):
+        * Shared/Plugins/NPObjectMessageReceiver.h:
+        * Shared/Plugins/NPRemoteObjectMap.cpp:
+        (WebKit::NPRemoteObjectMap::NPRemoteObjectMap):
+        (WebKit::NPRemoteObjectMap::invalidate):
+        * Shared/Plugins/NPRemoteObjectMap.h:
+        (WebKit::NPRemoteObjectMap::isInvalidating):
+
 2010-12-06  Sam Weinig  <sam at webkit.org>
 
         Reviewed by Anders Carlsson.
diff --git a/WebKit2/Shared/Plugins/NPObjectMessageReceiver.cpp b/WebKit2/Shared/Plugins/NPObjectMessageReceiver.cpp
index f0efb5d..013d849 100644
--- a/WebKit2/Shared/Plugins/NPObjectMessageReceiver.cpp
+++ b/WebKit2/Shared/Plugins/NPObjectMessageReceiver.cpp
@@ -32,6 +32,9 @@
 #include "NPRuntimeUtilities.h"
 #include "NPVariantData.h"
 
+// FIXME: This code shouldn't know about NPJSObject.
+#include "NPJSObject.h"
+
 namespace WebKit {
 
 PassOwnPtr<NPObjectMessageReceiver> NPObjectMessageReceiver::create(NPRemoteObjectMap* npRemoteObjectMap, uint64_t npObjectID, NPObject* npObject)
@@ -43,6 +46,7 @@ NPObjectMessageReceiver::NPObjectMessageReceiver(NPRemoteObjectMap* npRemoteObje
     : m_npRemoteObjectMap(npRemoteObjectMap)
     , m_npObjectID(npObjectID)
     , m_npObject(npObject)
+    , m_shouldReleaseObjectWhenInvalidating(!NPJSObject::isNPJSObject(npObject))
 {
     retainNPObject(m_npObject);
 }
@@ -51,6 +55,13 @@ NPObjectMessageReceiver::~NPObjectMessageReceiver()
 {
     m_npRemoteObjectMap->unregisterNPObject(m_npObjectID);
 
+    // If we're invalidating the remote object map, we don't always want to release the underlying NPObject.
+    // One example of this is NPJSObjects in the Web process, which have already been deallocated by the plug-in view.
+    // FIXME: This is not the ideal way to handle this. Maybe NPObjectMessageReceiver should be notified somehow when the underlying
+    // NPObject is deallocated.
+    if (m_npRemoteObjectMap->isInvalidating() && !m_shouldReleaseObjectWhenInvalidating)
+        return;
+
     releaseNPObject(m_npObject);
 }
 
diff --git a/WebKit2/Shared/Plugins/NPObjectMessageReceiver.h b/WebKit2/Shared/Plugins/NPObjectMessageReceiver.h
index d3363f9..cfb66e1 100644
--- a/WebKit2/Shared/Plugins/NPObjectMessageReceiver.h
+++ b/WebKit2/Shared/Plugins/NPObjectMessageReceiver.h
@@ -68,6 +68,7 @@ private:
     NPRemoteObjectMap* m_npRemoteObjectMap;
     uint64_t m_npObjectID;
     NPObject* m_npObject;
+    bool m_shouldReleaseObjectWhenInvalidating;
 };
     
 } // namespace WebKit
diff --git a/WebKit2/Shared/Plugins/NPRemoteObjectMap.cpp b/WebKit2/Shared/Plugins/NPRemoteObjectMap.cpp
index a7ca1dc..5fea618 100644
--- a/WebKit2/Shared/Plugins/NPRemoteObjectMap.cpp
+++ b/WebKit2/Shared/Plugins/NPRemoteObjectMap.cpp
@@ -49,6 +49,7 @@ PassRefPtr<NPRemoteObjectMap> NPRemoteObjectMap::create(CoreIPC::Connection* con
 
 NPRemoteObjectMap::NPRemoteObjectMap(CoreIPC::Connection* connection)
     : m_connection(connection)
+    , m_isInvalidating(false)
 {
 }
 
@@ -187,6 +188,10 @@ NPVariant NPRemoteObjectMap::npVariantDataToNPVariant(const NPVariantData& npVar
 
 void NPRemoteObjectMap::invalidate()
 {
+    ASSERT(!m_isInvalidating);
+
+    m_isInvalidating = true;
+
     Vector<NPObjectMessageReceiver*> messageReceivers;
     copyValuesToVector(m_registeredNPObjects, messageReceivers);
 
@@ -198,6 +203,8 @@ void NPRemoteObjectMap::invalidate()
     for (HashSet<NPObject*>::const_iterator it = m_npObjectProxies.begin(), end = m_npObjectProxies.end(); it != end; ++it)
         NPObjectProxy::toNPObjectProxy(*it)->invalidate();
     m_npObjectProxies.clear();
+
+    m_isInvalidating = false;
 }
 
 CoreIPC::SyncReplyMode NPRemoteObjectMap::didReceiveSyncMessage(CoreIPC::Connection* connection, CoreIPC::MessageID messageID, CoreIPC::ArgumentDecoder* arguments, CoreIPC::ArgumentEncoder* reply)
diff --git a/WebKit2/Shared/Plugins/NPRemoteObjectMap.h b/WebKit2/Shared/Plugins/NPRemoteObjectMap.h
index 1a731ea..ff0bbbb 100644
--- a/WebKit2/Shared/Plugins/NPRemoteObjectMap.h
+++ b/WebKit2/Shared/Plugins/NPRemoteObjectMap.h
@@ -60,6 +60,7 @@ public:
     NPVariant npVariantDataToNPVariant(const NPVariantData&);
 
     CoreIPC::Connection* connection() const { return m_connection; }
+    bool isInvalidating() const { return m_isInvalidating; }
 
     void invalidate();
 
@@ -69,6 +70,8 @@ private:
     explicit NPRemoteObjectMap(CoreIPC::Connection*);
     CoreIPC::Connection* m_connection;
 
+    bool m_isInvalidating;
+
     // A map of NPObjectMessageReceiver classes, wrapping objects that we export to the
     // other end of the connection.
     HashMap<uint64_t, NPObjectMessageReceiver*> m_registeredNPObjects;

-- 
WebKit Debian packaging