What steps will reproduce the problem?

(1) Install oopif-demo extension from https://bugs.chromium.org/p/chromium/issues/detail?id=487872#c4

(2) Make sure there isn't an existing extension process running for this extension.

(3) Go to http://csreis.github.io/tests/cross-site-iframe.html.  

(4) Navigate the subframe to (web-accessible) extension page from DevTools, e.g.: frames[0].location = "chrome-extension://ifheaekpohcmgkgdjnpiogkcohpanmok/options.html"

Alternatively, just go to https://www.chromium.org/, which has an OOPIF from that extension injected on the bottom.

(5) Inspect the OOPIF with devtools and check "chrome.windows".

What is the expected result?
chrome.windows points to a valid object.  E.g., chrome.windows.create() opens a new window.

What happens instead?
chrome.windows is undefined.

If you navigate to that extension options.html URL in a main frame, the JS bindings work.  Similarly, if you do that before step (3), the subframe will go into the existing extension process, and again the bindings will work fine.  I suspect because of this, this issue won't affect extensions with background pages (the one from step 1 doesn't have one).

It appears that in some cases, extensions JS bindings are injected in response to a RenderViewCreated notification: ExtensionWebContentsObserver::RenderViewCreated -> RendererStartupHelper::ActivateExtensionInProcess puts the RVH's process into pending_active_extensions_, which is later referenced to send ExtensionMsg_ActivateExtension.  However, WebContentsImpl::RenderViewCreated does *not* dispatch RenderViewCreated for inactive RVHs:

  // Don't send notifications if we are just creating a swapped-out RVH for
  // the opener chain.  These won't be used for view-source or WebUI, so it's
  // ok to return early.
  if (!static_cast<RenderViewHostImpl*>(render_view_host)->is_active())
    return;

So, if the RVH is created in swapped-out state, as is the case for an extension OOPIF, RendererStartupHelper will never learn about it. :(

There are a few things going on here with RenderViewCreated that we might want to fix, and it likely affects other observers as well.

1. For this particular case, should this go through RenderFrameCreated instead?

2. Should we be also dispatching RenderViewCreated for swapped-out RVHs?  There are many other observers affected, and I'd guess some of them can't deal with the RVH being swapped-out, so this seems risky.  But cases like this show that we might also have other bugs here.

3. Should we be at least dispatching RenderViewCreated when a swapped-out RVH becomes active, for example after a remote-to-local main frame navigation in an opener tab?  We don't seem to do that either.

I found this while experimenting with always doing remote-to-local transitions on cross-process navigations as part of issue 756790, which means that in those cases the RVH will start swapped-out and transition to active when the main frame commits.

I reproed this on both Mac and Windows canary (62.0.3199.0).