I might be able to fix this as a prerequisite for issue 905513 - draft CL at https://chromium-review.googlesource.com/c/chromium/src/+/1343516.

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

commit 25754cd4d3832e74532b6e67eea0eae260869900
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Wed Dec 05 22:43:08 2018

Remove isolated origin workarounds from CCBCEP::GetEffectiveURL().

Previously, if a hosted app's web extent matched one or more isolated
origins, we used complicated logic in
ChromeContentBrowserClientExtensionsPart::GetEffectiveURL to determine
when a URL was allowed to go into a hosted app process (by utilizing
an effective site URL) without compromising the security of isolated
origins.  Specifically, if a hosted app was contained entirely within
an isolated origin, then we decided it was safe to place any app URL
into an app process.  This is because we used to have an issue,
 https://crbug.com/791796 , where all origins covered by the app would
end up in the *same* app process, which could break process isolation
for isolated origins.

This logic is no longer needed after we started locking hosted app
processes to origin, which fixed  https://crbug.com/791796  and allowed
a hosted app to span multiple processes.  Given that work, if a hosted
app corresponds to different isolated origins, it's safe to simply
load those origins in different app processes.  Therefore, this CL
removes that logic and allows any URL covered by an app to load in an
app process.  If any of those URLs match isolated origins, they will
simply swap to a different app process -- no additional changes were
needed for this.

For example, suppose there's one isolated origin,
http://isolated.origin.com, and a hosted app's extent covers foo.com
and isolated.origin.com.  Suppose a main frame at foo.com (in app
process) embeds an iframe for http://isolated.origin.com.  Previously,
we'd kick the iframe into an OOPIF, with site URL of
http://isolated.origin.com, locked to http://isolated.origin.com, and
in a non-app process.  After this CL, we'd still kick the iframe into
an OOPIF, locked to https://isolated.origin.com, but it will have a
site URL of chrome-extension://appid/#https://isolated.origin.com, and
it will actually be in its own app process.  This is arguably more
correct, and should make hosted apps more compatible with isolated
origin uses.

Another motivation for this change is that it removes the only use of
ChildProcessSecurityPolicy::GetMatchingIsolatedOrigin outside of
content/.  That API will need to be updated to support dynamic
isolated origins (see issue 905513), and this will be easier to do if
this use case is removed.

Bug:  879722 , 718516, 905513
Change-Id: Ia60e1ad435d58c66a02730a1459ab0684fad89d1
Reviewed-on: https://chromium-review.googlesource.com/c/1343516
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#614144}
[modify] https://crrev.com/25754cd4d3832e74532b6e67eea0eae260869900/chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
[modify] https://crrev.com/25754cd4d3832e74532b6e67eea0eae260869900/chrome/browser/extensions/chrome_content_browser_client_extensions_part.h
[modify] https://crrev.com/25754cd4d3832e74532b6e67eea0eae260869900/chrome/browser/extensions/chrome_content_browser_client_extensions_part_unittest.cc
[modify] https://crrev.com/25754cd4d3832e74532b6e67eea0eae260869900/chrome/browser/ui/extensions/hosted_app_browsertest.cc
[modify] https://crrev.com/25754cd4d3832e74532b6e67eea0eae260869900/content/browser/child_process_security_policy_impl.h
[modify] https://crrev.com/25754cd4d3832e74532b6e67eea0eae260869900/content/public/browser/child_process_security_policy.h