Currently, devtools extension iframes are allowed to stay in the devtools process. This exception was added to RenderFrameHostManager::IsRendererTransferNeededForNavigation as a quick fix for issue 564216 . It avoids the process swap for the extension's devtools_page as well as panels and sidebar panes that it creates (all of these are iframes).
As part of the discussion on https://codereview.chromium.org/2646683002/, we discovered that it's actually possible to kick devtools extensions out of process. The devtools APIs are all written on top of postMessage, and there are no other synchronous scripting requirements of any kind. According to caseq@, the main issue to resolve is changing how the devtools extension APIs are injected. Currently, that relies on DevToolsHost::setInjectedScriptForOrigin [1], which only works within a single renderer. Instead, we'll need to inject the script APIs from the browser; dgozman@ suggests watching for the matching frames in DevToolsUIBindings::FrontendWebContentsObserver::ReadyToCommitNavigation and
injecting the API script from there.
This should further strengthen the security model for --isolate-extensions and remove one of the last cases where a chrome-extension:// URL isn't rendered in an extension process. We'll try to work on this in Q2.
A few more notes from recent discussions:
- Doing this should allow us to remove the devtools scheme checks from RFHM::IsRendererTransferNeededForNavigation and DetermineSiteInstanceForURL. Devtools extension process swaps would be handled just like all other process swaps. In issue 564216 , we were crashing on the devtools extension transfer path, but that's not happening anymore, probably because we're shortcutting transfers not to go through the OpenURL path anymore.
- It should be fine, and in fact desirable, to put the devtools_page, panels, and sidebar panes into the extension process along with the rest of the extension. Nick and I discussed whether we might need to invent a new type of process with devtools extension API access but without other extension privileges, but there seems to be no fundamental reason for separating the privileges, and putting everything into the extension process would simplify lives of developers who currently have to use message passing between the devtools and non-devtools parts of their extension. We should be careful to only grant script API access to devtools extension iframes within the devtools window.
- For cases like devtools -> devtools_page -> panel -> web iframe -> devtools extension iframe, there's the question of whether the bottom devtools extension iframe should get devtools extension APIs. Devtools folks seem to be fine either way, davidsac@ mentioned that APIs aren't granted in such cases today, and we might as well keep it that way to minimize the privileges.
[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/devtools/front_end/extensions/ExtensionServer.js?l=765
Comment 1 by nick@chromium.org
, Mar 29 2017