Suppress ScriptForbiddenScope in Document.cpp and FrameView.cpp in release mode

Source/web/WebPluginContainerImpl.cpp

Index: Source/web/WebPluginContainerImpl.cpp
diff --git a/Source/web/WebPluginContainerImpl.cpp b/Source/web/WebPluginContainerImpl.cpp
index 4808407bbae8597afa6362b404616222c5ea9809..1d49b34d5ff80a8175f156df7b00a892f170624f 100644
--- a/Source/web/WebPluginContainerImpl.cpp
+++ b/Source/web/WebPluginContainerImpl.cpp
@@ -684,6 +684,8 @@ WebPluginContainerImpl::~WebPluginContainerImpl()
         m_element->document().didRemoveTouchEventHandler(m_element);
 #endif
 
+    ScriptForbiddenScope::SuppressScriptForbiddenScopeInRelease thisSuppressionShouldBeRemoved;

[haraken, 2014/07/19 03:39:49]

It's scary we're invoking JavaScript inside a destructor...

See a stack trace: https://code.google.com/p/chromium/issues/detail?id=395299

sof@: Probably is this problematic in oilpan? ~WebPluginContainerImpl() can
execute arbitrary JavaScript.

Either way I think we should land this CL sooner to fix outstanding release
block bugs.

[sof, 2014/07/19 06:14:43]

I can't access that one (Cc: me if you like, might help..), but I'm guessing
this happens when allowing scripting when calling PluginDestroyed on the plugin;
see
content/renderer/npapi/webplugin_impl.cc:WebPluginImpl::TearDownPluginInstance()
Calling into v8 during sweeping is definitely problematic. To quote ager when
this came earlier as a possible reason for a crash seen,

   "Entering V8 during sweeping (either weak processing or finalization) can
lead to nested GCs which we do not support."

+
     for (size_t i = 0; i < m_pluginLoadObservers.size(); ++i)
         m_pluginLoadObservers[i]->clearPluginContainer();
     m_webPlugin->destroy();