[HBD] Remove PluginCache and reload plugin list when origin changes

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

Index: third_party/WebKit/Source/core/dom/DOMImplementation.cpp
diff --git a/third_party/WebKit/Source/core/dom/DOMImplementation.cpp b/third_party/WebKit/Source/core/dom/DOMImplementation.cpp
index 5c7975e2c94c5fb777ecb1d96de93c7e7abc6cf0..4a11df24372cfb0431454cdbe366690c54c703c9 100644
--- a/third_party/WebKit/Source/core/dom/DOMImplementation.cpp
+++ b/third_party/WebKit/Source/core/dom/DOMImplementation.cpp
@@ -225,9 +225,11 @@ Document* DOMImplementation::createDocument(const String& type, const DocumentIn
     if (type == "application/xhtml+xml")
         return XMLDocument::createXHTML(init);
 
-    PluginData* pluginData = 0;
-    if (init.frame() && init.frame()->page() && init.frame()->loader().allowPlugins(NotAboutToInstantiatePlugin))
-        pluginData = init.frame()->pluginData();
+    PluginData* pluginData = nullptr;
+    if (init.frame() && init.frame()->page() && init.frame()->loader().allowPlugins(NotAboutToInstantiatePlugin)) {
+        SecurityContext* mainFrameSecurityContext = init.frame()->page()->mainFrame()->securityContext();
+        pluginData = init.frame()->page()->pluginData(mainFrameSecurityContext ? mainFrameSecurityContext->getSecurityOrigin() : SecurityOrigin::create(init.url()).get());

[dcheng, 2016/08/23 05:51:55]

Hm, so when we create the document for the main frame, mainFrameSecurityContext
will always be null (since the document will have just been cleared in
installNewDocument). So this always ends up going through the
SecurityOrigin::create(init.url()) path. This juat happens to (mostly) match the
behavior of Document::initSecurityContext, but there's no actual guarantee, so
it feels fragile.

- A top-level frame can never be sandboxed (I think?) so we never need to create
a unique origin.
- A top-level frame can have an owner (opener), so the origin of the initial
empty document would actually be the origin of its opener. But perhaps it's OK
to just treat this as unique?
- Otherwise, we follow the same path as setting the security origin for a main
frame...

I wonder if it would it be better to be explicit about the main frame thing
here?

For subframes, the main frame security context must always be already
initialized. And for the main frame, we should just use an origin derived from
the document URL (even if the URL is something like about:blank).

[tommycli, 2016/08/23 17:31:03]

For the purposes of retrieving the plugin data, we always want the origin of the
new main frame. So if the document is at foo.com/bar.swf, we always want foo.com
to be the origin.

It's probably misleading to even call it a security origin, it's more like: the
domain used for Site Settings.

Actually part of your comment confused me. Why does Document set its own
security origin to that of the opener? I think I don't understand security
origins that well.

[trizzofo, 2016/08/23 22:46:20]

I changed it to use Frame's IsMainFrame() method. Hopefully it's more explicit.
ptal.

+    }
 
     // PDF is one image type for which a plugin can override built-in support.
     // We do not want QuickTime to take over all image types, obviously.