New issue
Advanced search Search tips

Issue 711006 link

Starred by 1 user
Status: Fixed
Owner:
alex...@chromium.org
Closed: May 2017
Cc:
creis@chromium.org
wfh@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Navigating a subframe from an isolated URL to a non-isolated URL doesn't go back to parent frame's process

Project Member Reported by alex...@chromium.org, Apr 12 2017 
Suppose a page foo.com, where foo.com does not require a dedicated process, embeds an iframe and navigates it to a URL on isolated.com, which does require a dedicated process.  This will create an OOPIF.

Next, suppose the page navigates that iframe to bar.com, which is cross-site from the parent page, but does not require a dedicated process.  This should bring the bar.com navigation back to the parent process, but instead it keeps it in an OOPIF in a new process and a bar.com SiteInstance.

Repro steps for --isolate-extensions:
(1) Install oopif-demo extension from https://bugs.chromium.org/p/chromium/issues/detail?id=487872#c4
(2) Go to https://www.chromium.org.  There should be an extension OOPIF on the bottom.
(3) From devtools, execute
document.querySelector('iframe').src = "https://www.asdf.com"
(4) Check task manager.  The navigated iframe is left as an OOPIF for asdf.com, instead of being placed back into chromium.org's process.

This is probably not a huge problem for --isolate-extensions, where we don't expect many extensions iframes to be navigated to a (different) web site, but it will be more problematic for other OOPIF modes, leading to more OOPIFs than necessary.
Project Member

Comment 1 by bugdroid1@chromium.org, Apr 17 2017 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/24409702df38cbd9505f1cae180be98d2f7e148d

commit 24409702df38cbd9505f1cae180be98d2f7e148d
Author: alexmos <alexmos@chromium.org>
Date: Mon Apr 17 23:13:31 2017

Don't create unnecessary OOPIFs for subframe navigations that don't require a dedicated process.

Previously, if we had a.com embedding chrome-extension://foo, and the
subframe was navigated to b.com (with --isolate-extensions being on by
default but without any other OOPIF modes), the subframe stayed in an
OOPIF in a new process for b.com, even though technically the b.com
OOPIF is not necessary per --isolate-extensions security model.  This
CL fixes that.

BUG= 711006 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2809653008
Cr-Commit-Position: refs/heads/master@{#465055}

[modify] https://crrev.com/24409702df38cbd9505f1cae180be98d2f7e148d/chrome/browser/extensions/process_manager_browsertest.cc
[modify] https://crrev.com/24409702df38cbd9505f1cae180be98d2f7e148d/content/browser/frame_host/render_frame_host_manager.cc

Comment 2 by alex...@chromium.org, May 4 2017

Status: Fixed (was: Started)
This particular repro should be fixed - verified in 60.0.3086.0 canary.  However, I've realized there are more ways of getting multiple web processes within a frame tree.  E.g., if in step (3), we instead inspect the extension subframe and add a new iframe that points to https://www.asdf.com, the grandchild will get its own subframe process rather than go back into chromium.org's process.  It seems we could technically consolidate the two web processes into one for --isolate-extensions, so we will need stronger heuristics if we ever want that.
►

Sign in to add a comment