Fix pepper crash when reattaching plugins in style recalc

third_party/WebKit/Source/core/dom/Document.cpp

Index: third_party/WebKit/Source/core/dom/Document.cpp
diff --git a/third_party/WebKit/Source/core/dom/Document.cpp b/third_party/WebKit/Source/core/dom/Document.cpp
index 8fef529d996e416d456b2efc891fcbca9a0a3156..66fc156b7f66e420f960ecb4d70a6e684bef7482 100644
--- a/third_party/WebKit/Source/core/dom/Document.cpp
+++ b/third_party/WebKit/Source/core/dom/Document.cpp
@@ -1729,6 +1729,10 @@ void Document::updateLayoutTree(StyleRecalcChange change)
     ASSERT(isMainThread());
 
     ScriptForbiddenScope forbidScript;
+    // We should forbid script execution for plugins here because update while layout is changing,
+    // HTMLPlugin element can be reattached and plugin can be destroyed. Plugin can execute scripts
+    // on destroy. It produces crash without PluginScriptForbiddenScope: crbug.com/550427.
+    PluginScriptForbiddenScope pluginForbidScript;

[dcheng, 2016/02/12 20:09:12]

Note that the reason this works is because some parts of Blink now assert that
we're not in a script forbidden scope before trying to execute script:
previously, we would just return and do nothing.

PluginScriptForbiddenScope is ultimately used by code that implements WebPlugin
in content (?): if //content detects one of these is on the stack, it just won't
try to execute script at all, bypassing the asserts.

[pfeldman, 2016/02/17 01:20:31]

How would /core contributor know when to use ScriptForbidden vs
PluginScriptForbidden and why?

[esprehn, 2016/02/18 02:17:30]

PluginScriptForbidden is poorly named, it's more like
PluginDOMScriptingDisabler. It allows plugin scripts to still run, but they're
forbidden from calling back into blink to execute script I think.

In the case of this patch it works by breaking some things in flash probably...
but that's also probably fine. Flash is buggy that it's messing with the page
inside creation/destruction.

 
     if (!view() || !isActive())
         return;