OOPIF: make --single-process and --process-per-tab behave sanely when combined with --site-per-process or other OOPIF modes |
||
Issue descriptionLaunching Chrome with both --single-process and --site-per-process currently breaks cross-process navigations. Easy repro: go to http://csreis.github.io/tests/cross-site-iframe.html and click on "Go cross-site". The frame navigation will hang without ever completing. Same bug also happens for a window.open() to a cross-site URL. Same for an extension with web iframes under --isolate-extensions (and this will happen by default once we ship --isolate-extensions). --single-process is not supported, so I don't know whether we actually want to fix this. If we do fix this, presumably we want --single-process to trump OOPIF modes and complete the navigation in the single process. I also don't know whether we still rely on any of the single-process code anywhere (e.g., in Android webview), which might make this more important. I don't see broken navigations with --process-per-tab, but it does appear that --site-per-process wins if both flags are passed (i.e., browser-initiated top-level navigations swap processes, whereas they wouldn't normally do this under --process-per-tab). We should think about whether this is the right behavior. Charlie initially brought this up in https://codereview.chromium.org/2668013005/diff/20001/content/browser/frame_host/render_frame_host_manager.cc, where the checks in RenderFrameHostManager::ShouldTransitionCrossSite seem to be at least part of the problem.
,
May 1 2017
#1: Yes, I think that's expected (for most sites) in both the default process model and with --process-per-tab, as these are treated as different types of navigations (renderer-initiated vs. browser-initiated). http://www.chromium.org/developers/design-documents/process-models and https://blog.chromium.org/2009/12/links-that-open-in-new-processes.html have a bit more detail.
,
May 1 2017
Comments 1-2: Sorry for missing this earlier. --process-per-tab is not supposed to swap processes for most cross-site navigations, even browser-initiated ones like typing in the address bar. (The exception is for privilege level changes, like NTP or WebUI.) I checked and it looks like you're correct about this being a bug for normal cross-site navigations. Can you file a different issue for it and let us know the issue number?
,
May 2 2017
Submitted issue 717459
,
Jul 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0b49fa16f0265a0b1274383546fe933c288d2106 commit 0b49fa16f0265a0b1274383546fe933c288d2106 Author: creis <creis@chromium.org> Date: Mon Jul 10 16:31:11 2017 Disable cross-process navigations in --single-process. This flag takes precedence over --site-per-process and other site isolation modes. BUG=688617 TEST=Cross-site subframes work with --single-process --site-per-process CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation Review-Url: https://codereview.chromium.org/2964033002 Cr-Commit-Position: refs/heads/master@{#485292} [modify] https://crrev.com/0b49fa16f0265a0b1274383546fe933c288d2106/content/browser/frame_host/render_frame_host_manager.cc [modify] https://crrev.com/0b49fa16f0265a0b1274383546fe933c288d2106/content/browser/frame_host/render_frame_host_manager.h [modify] https://crrev.com/0b49fa16f0265a0b1274383546fe933c288d2106/content/browser/site_instance_impl.cc [modify] https://crrev.com/0b49fa16f0265a0b1274383546fe933c288d2106/content/public/common/content_switches.cc
,
Jul 11
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||
►
Sign in to add a comment |
||
Comment 1 by land...@opera.com
, Apr 25 2017