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

third_party/WebKit/Source/core/page/Page.cpp

Index: third_party/WebKit/Source/core/page/Page.cpp
diff --git a/third_party/WebKit/Source/core/page/Page.cpp b/third_party/WebKit/Source/core/page/Page.cpp
index 4e2a89a2e20ff22690e5f00de814170cd6d4b0ce..6b4cdb884e8b106fa1e259e6469c66fa9c4f5619 100644
--- a/third_party/WebKit/Source/core/page/Page.cpp
+++ b/third_party/WebKit/Source/core/page/Page.cpp
@@ -54,6 +54,7 @@
 #include "platform/plugins/PluginData.h"
 #include "platform/text/CompressibleString.h"
 #include "public/platform/Platform.h"
+#include "public/platform/WebSecurityOrigin.h"
 
 namespace blink {
 
@@ -243,10 +244,17 @@ void Page::refreshPlugins()
     }
 }
 
-PluginData* Page::pluginData() const
+PluginData* Page::pluginData()
 {
-    if (!m_pluginData)
-        m_pluginData = PluginData::create(this);
+    SecurityContext* context = mainFrame()->securityContext();
+    // Frame::securityContext() may return null in tests. For that reason,
+    // whenever it's null, an unique SecurityOrigin is created instead.

[dcheng, 2016/08/03 14:34:58]

Which tests? Can we fix the tests? Putting test-only logic in not test code
makes me sad.

[trizzofo, 2016/08/03 19:11:18]

There are quite a few of them. You can see it in Patch Set 4 trybots.
Apparently, LocalFrame::securityContext() returns nullptr when it's
LocalDomWindow is null. Can that happen outside tests?

[tommycli, 2016/08/03 20:53:39]

I agree it would be ideal to fix the tests. dcheng: Would a TODO be
satisfactory?

[alexmos, 2016/08/04 05:32:03]

LocalFrame::securityContext() just returns the LocalFrame's Document.

Looks like all those tests fail with the same stack, during new (likely
top-level) Document initialization, when we're deciding what kind of Document to
create in DOMImplementation::createDocument:

Received signal 11 SEGV_MAPERR 000000000008
#0 0x00000280d0d7 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#1 0x7f2b8d81acb0 <unknown>
#2 0x00000586bcf9 blink::Page::pluginData()
#3 0x00000526f3be blink::DOMImplementation::createDocument()
#4 0x000005758b99 blink::LocalDOMWindow::createDocument()
#5 0x000005758cac blink::LocalDOMWindow::installNewDocument()
#6 0x000005821e86 blink::DocumentLoader::createWriterFor()
#7 0x000005821d18 blink::DocumentLoader::ensureWriter()
#8 0x000005820df8 blink::DocumentLoader::commitData()
#9 0x000005820c53 blink::DocumentLoader::finishedLoading()
...

Which makes sense - at this point the new Document isn't even created yet.  Note
that this happens in browser_tests as well, so it's not like it's caused by some
unit test setup weirdness.

Can you double-check that this path actually works?  Maybe investigate one of
the failing browser_tests?  At the point in the crash, the new document's origin
isn't initialized yet (we haven't decided what kind of document to create yet),
and I'm not sure you want this to actually use a unique origin, rather than,
say, the url or the owner()'s origin from the DocumentInit.

[trizzofo, 2016/08/05 02:04:26]

Yes, you're right. I took a better look at DOMImplemetation::createDocument()
and the PluginData is fetched if the document type is different from text/html
and application/xhtml+xml. I managed to reproduce the crash locally by opening
an image page.

To solve this, we created a temporary PluginData instance based on DocumentInit
information. Please take a look at patch set 9.

+    RefPtr<SecurityOrigin> mainFrameOrigin = context ? context->getSecurityOrigin() : SecurityOrigin::createUnique().get();
+    WebSecurityOrigin webOrigin(mainFrameOrigin.get());
+
+    if (!m_pluginData || !mainFrameOrigin->isSameSchemeHostPort(m_mainFrameOrigin.get()))
+        m_pluginData = PluginData::create(webOrigin);
+    m_mainFrameOrigin = mainFrameOrigin;
     return m_pluginData.get();
 }