Fix navigator.plugins and navigator.mimeTypes for OOPIFs.

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

 /*
  * Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 Apple Inc. All Rights Reserved.
  * Copyright (C) 2008 Torch Mobile Inc. All rights reserved. (http://www.torchmobile.com/)
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
  * License as published by the Free Software Foundation; either
  * version 2 of the License, or (at your option) any later version.
  * This library is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
@@ skipping 240 matching lines @@
 
     for (const Page* page : allPages()) {
         // Clear out the page's plugin data.
         if (page->m_pluginData)
             page->m_pluginData = nullptr;
     }
 }
 
 PluginData* Page::pluginData() const
 {
-    if (!mainFrame()->isLocalFrame()
-        || !deprecatedLocalMainFrame()->loader().allowPlugins(NotAboutToInstantiatePlugin))

[alexmos, 2016/05/19 18:21:56]

AFAICT, the places which called this didn't rely on allowPlugins being called on
the main frame: several places also call allowPlugins directly on the frame, and
the client calls like ContentSettingsObserver::allowPlugins don't care about the
frame.  (ContentSettingsObserver::didNotAllowPlugins actually sends a message
via the frame to the browser, but the handler is
TabSpecificContentSettings::OnContentBlockedWithDetail and doesn't use the
frame)

-        return nullptr;
     if (!m_pluginData)
         m_pluginData = PluginData::create(this);
     return m_pluginData.get();

[Nate Chapin, 2016/05/19 19:44:40]

Semi-tangential: What are the rules on what goes on FrameHost vs. Page? Should
we move m_pluginData to FrameHost while we're here? Also, it's not entirely
clear to me, but it's possible that we could make PluginData per-process rather
than per-page?

[dcheng, 2016/05/19 20:04:37]

At one point, I believe the plan for FrameHost was to move things shared by
Frames but agnostic to Frame relationships (e.g. Settings) to FrameHost while
things that are shared by Frames but care about Frame relationships (e.g.
FocusController) would move to Page. I don't think there's anyone actively
working on this, and the split is kind of confusing, so maybe we should just
merge the two for now.

[alexmos, 2016/05/19 22:23:27]

Yeah, I think the best cleanup for this is actually to make pluginData
per-process rather than per-page.  Ultimately, the data comes from pluginCache()
in PluginData.cpp, where the data is already per-process as a
DEFINE_STATIC_LOCAL: 
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
AFAICT, nothing in PluginData.cpp depends on Page, even though it's passed in
(maybe it used to?), so perhaps it's just possible to retrieve the necessary
data from that cache directly, without involving Page at all.  There'd be a few
more things to figure out (like refresh), so if it's ok, I'm going to leave this
for a followup CL.

 }
 
 void Page::unmarkAllTextMatches()
 {
     if (!mainFrame())
         return;
 
     Frame* frame = mainFrame();
     do {
         if (frame->isLocalFrame())
@@ skipping 299 matching lines @@
 {
 }
 
 Page::PageClients::~PageClients()
 {
 }
 
 template class CORE_TEMPLATE_EXPORT Supplement<Page>;
 
 } // namespace blink