summaryrefslogtreecommitdiffstats
path: root/content/renderer/webplugin_delegate_proxy.cc
diff options
context:
space:
mode:
authorwez@chromium.org <wez@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2011-09-06 23:52:06 +0000
committerwez@chromium.org <wez@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2011-09-06 23:52:06 +0000
commit4c78f7a2bde646d8dec227c06e26e77e406e7f72 (patch)
treeabd1362cf90340ce2a6e38fed7447ce84eee0fb5 /content/renderer/webplugin_delegate_proxy.cc
parent60550c8109b8b14a2d37fbd3fcda41a77f006f44 (diff)
downloadchromium_src-4c78f7a2bde646d8dec227c06e26e77e406e7f72.zip
chromium_src-4c78f7a2bde646d8dec227c06e26e77e406e7f72.tar.gz
chromium_src-4c78f7a2bde646d8dec227c06e26e77e406e7f72.tar.bz2
Remove the detach-but-don't-release special-case for the window script object.
- Why remove the special case? WebKit's script controllers have a special-case for the window script object, which deallocates it regardless of reference-count, on the assumption that by the time the relevant call (clearScriptObjects) is made, no callers can remain which hold references to it - this prevents it from lingering indfinitely if the plugin forgets to release it. WebPluginDelegateProxy has a special-case for handling the window script object, which tries to cope with the case where clearScriptObjects has been called before the plugin is destroyed (which should never happen), by avoiding trying to release the window script object, and instead relying on WebKit deallocating it. This workaround doesn't actually work; if WebKit is behaving then the object exists at plugin teardown time, and it's safe for code to touch it. If it doesn't exist any more, then we may still touch it if the plugin tries to script the window, or to release the reference. Even if neither of those occur, the stub for the object may release it when the last plugin instance's channel is torn-down, before the workaround can be hit. We still need to explicitly tear-down the window script object's stub if the plugin failed to release it, so that it won't linger and end up being released after WebKit has already deallocated it. Review URL: http://codereview.chromium.org/7696016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@99869 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'content/renderer/webplugin_delegate_proxy.cc')
-rw-r--r--content/renderer/webplugin_delegate_proxy.cc13
1 files changed, 7 insertions, 6 deletions
diff --git a/content/renderer/webplugin_delegate_proxy.cc b/content/renderer/webplugin_delegate_proxy.cc
index 8ffd930..e26129b 100644
--- a/content/renderer/webplugin_delegate_proxy.cc
+++ b/content/renderer/webplugin_delegate_proxy.cc
@@ -219,12 +219,13 @@ void WebPluginDelegateProxy::PluginDestroyed() {
}
if (window_script_object_) {
- // The ScriptController deallocates this object independent of its ref count
- // to avoid leaks if the plugin forgets to release it. So mark the object
- // invalid to avoid accessing it past this point. Note: only do this after
- // the DestroyInstance message in case the window object is scripted by the
- // plugin in NPP_Destroy.
- window_script_object_->DeleteSoon(false);
+ // Release the window script object, if the plugin didn't already.
+ // If we don't do this then it will linger until the last plugin instance is
+ // destroyed. In the meantime, though, the frame that it refers to may have
+ // been destroyed by WebKit, at which point WebKit will forcibly deallocate
+ // the window script object. The window script object stub is unique to the
+ // plugin instance, so this won't affect other instances.
+ window_script_object_->DeleteSoon();
}
plugin_ = NULL;