FWIW, I have a browser test exposing this bug at https://chromium-review.googlesource.com/#/c/chromium/src/+/783470:

../../content/browser/isolated_origin_browsertest.cc:962: Failure
      Expected: c1->GetProcess()->GetID()
      Which is: 4
To be equal to: c2->GetProcess()->GetID()
      Which is: 5
[145481:145481:1121/125202.156345:INFO:CONSOLE(3)] "Uncaught SecurityError: Blocked a frame with origin "http://c.com:33561" from accessing a frame with origin "http://c.com:33561". Protocols, domains, and ports must match.", source: http://c.com:33561/cross_site_iframe_factory.html?c() (3)

Also, https://bugs.chromium.org/p/chromium/issues/detail?id=512560#c5 has non-test repro steps for this.

This bug doesn't repro in --site-per-process mode, because in this mode c2 will find the site instance to reuse via BrowsingInstance::GetSiteInstanceForURL (BrowsingInstance maintains a site_url->SiteInstance map).

I wonder how feasible it would be to not use "http://b.com" or "http://d.com" as a site_url, but instead use something like "http://general.non.isolated.web.com" as a site_url.  I think that in this case b and d frame would share a process and therefore c1 and c2 would also share a process.

Another option might be to leave b.com and d.com as separate SiteInstances, but tweak the process reuse logic to always prefer reusing an existing, suitable (as determined by IsSuitableHost) process for frames in the same BrowsingInstance.

Or maybe BrowsingInstance (in addition to maintaining site_url->SiteInstance map) can remember a pointer to a "open" SiteInstance (a SiteInstance where DoesSiteRequireDedicatedProcess is false) and reuse this SiteInstance if possible from BrowsingInstance::GetSiteInstanceForURL.

I have a WIP CL @ https://crrev.com/c/783470

Potential next steps before or during CR:

- Verify the tryjobs are green.

- Understand how subframe reused works for --isolate-extensions (maybe the old code is not needed anymore after my changes in the CL above?).

- Discuss whether b+c+d consolidation is desirable (or if we should only consolidate c1+c2 while keeping b and d separate).

Interestingly the CL from #c6 means that a browser-initiated a.com -> b.com navigation does NOT swap processes (assumming that a.com and b.com do not require a dedicated process).  I don't know if this is desirable and/or okay - let's discuss this next week.

FWIW, the CL from #c6 makes a lot of tests red (but failures I've looked at so far are just caused by incorrect test assumptions about process swaps).

We might want to bump up the priority on the consolidation aspect of this issue, since it could help with sad frame regressions for Android, by conserving resources and reducing process count when isolating a subset of sites.  For example, for a page A(B,C,D), we might want to put B/C/D into the same process.

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

commit 4726a173d112e32079b01138c4745e966d7adc02
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Mon Oct 15 21:25:10 2018

DCHECK(browser_context) in most methods of ContentBrowserClient.

ContentBrowserClients assume that |browser_context| client is not null
(e.g. HeadlessContentBrowserClient::DoesSiteRequireDedicatedProcess and
ChromeContentBrowserClientExtensionsPart::DoesSiteRequireDedicatedProcess).
To avoid surprises, this CL adds DCHECK(browser_context) to most methods
of ContentBrowserClients, so that the assumption is documented and
verified during //content-layer tests.

Bug: 787576
Change-Id: I115ab53bb64cebe50b5993a39b3e153e3054b1b3
Reviewed-on: https://chromium-review.googlesource.com/c/1276559
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599752}
[modify] https://crrev.com/4726a173d112e32079b01138c4745e966d7adc02/content/browser/browsing_instance.cc
[modify] https://crrev.com/4726a173d112e32079b01138c4745e966d7adc02/content/browser/child_process_security_policy_impl.cc
[modify] https://crrev.com/4726a173d112e32079b01138c4745e966d7adc02/content/browser/frame_host/navigation_entry_impl_unittest.cc
[modify] https://crrev.com/4726a173d112e32079b01138c4745e966d7adc02/content/browser/service_worker/embedded_worker_instance.cc
[modify] https://crrev.com/4726a173d112e32079b01138c4745e966d7adc02/content/browser/service_worker/service_worker_process_manager.cc
[modify] https://crrev.com/4726a173d112e32079b01138c4745e966d7adc02/content/browser/site_instance_impl.cc
[modify] https://crrev.com/4726a173d112e32079b01138c4745e966d7adc02/content/browser/site_instance_impl_unittest.cc
[modify] https://crrev.com/4726a173d112e32079b01138c4745e966d7adc02/content/public/browser/content_browser_client.cc

Per #c9, we'll want to finish this work for launching site isolation on Android, as it's expected to provide important process consolidation benefits there, so adding appropriate label.
 
Just as a status update, the approach we're currently pursuing is to stick all sites that don't require a dedicated process into a "nonisolated.invalid" SiteInstance.   lukasza@ put together a design doc for this at https://docs.google.com/document/d/1uiaNe2vhZsYfLQsaCuD-OEQhN-dCI_3YhkHGVU1a5CM, as well as a draft CL at https://chromium-review.googlesource.com/c/chromium/src/+/1252534.  Doing this requires answering DoesSiteRequireDedicatedProcess on the IO thread (as part of GetSiteForURL), and this in turn needs to know the profile (due to extensions, and soon, profile-scoped dynamic isolated origins).  acolwell@ is currently working on ensuring that we can access profile information on the IO thread - see issue 898281.