I am guessing that this particular bug can be fixed by tweaking ChromeContentBrowserClient::ShouldFrameShareParentSiteInstanceDespiteTopDocumentIsolation that was introduced when fixing a similar bug ( issue 665109 ) in r432951.

We discussed the following scenario:
- MF: Main frame: Docs hosted app (document.origin = "https://docs.google.com", effective URI is a chrome-extension URI)
- SF1: Subframe from client5.google.com origin
- SF2: Hypothetical subframe from another.site.com origin

Putting SF1 in the same process as MF is needed to fix the current bug.  Putting SF2 in the same process as MF is optional (creis@ suggested this shortcut and nick@ is okay with it).  Leaving placement of SF2 undefined means that we can fix this bug by simply disabling TDI if the parent SiteInstance belongs to a hosted app.  This way we avoid having to compare real URL of the parent (or web extent patterns of the parent) with the site of the subframe (which is doable and not that difficult, but definitely adds non-trivial amount of code and maintenance burden going forward). 

To reinforce #c2, nick@ helped with a small experiment and it seems that --isolate-extensions (in absence of TDI) doesn't kick out a cross-site subframe out of a hosted app's renderer process (*).  This experiment shows that (at least today) the decision whether to kick a cross-site frame into a separate process from a hosted app is purely a TDI decision (and not an --isolate-extensions decision).

(*) The scenario we looked at was
1) launching docs app,
2) verifying that a tab shows https://docs.google.com in omnibox while having access to chrome.app APIs,
3) using DevTools to add a cross-site iframe (https://anforowicz.github.io/frame-creation-order/index.htm),
4) looking at the task manager to see that the new iframe didn't get kicked out to a separate renderer process).  

I've verified that this bug also represents a functionality problem that creis@ alluded to in the original comment.  I am not sure how often this is a problem in practice, but in a test I see that http://app.site.com/save_page/a.htm trying to script http://app.site.com/frame_tree/simple.htm (when only the latter one is covered by the hosted app's web extent) gives a hilarious error message: Uncaught SecurityError: Blocked a frame with origin "http://app.site.com:35938" from accessing a frame with origin "http://app.site.com:35938". Protocols, domains, and ports must match.

This bug is not limited to --top-document-isolation - it also affects other isolation modes (e.g. #c4 repros with --site-per-process).

BTW: To repro the issue in #c4 and #c5 we don't really need a hosted app extent that covers *path*.  The same issue will repro for app.site.com (covered by hosted app's extent) and other.site.com (not covered) if they both use window.domain.

I am mentioning this for completeness.  I don't want to comment for now how common is such usage of window.domain and/or hosted apps.

If we wanted to host app.site.com and other.site.com in the same process even with --site-per-process, then I *think* we need to:

1. Stop treating PRIV_HOSTED as separate from PRIV_NORMAL for purpose of calculating IsSuitableHost.

2. Get RenderFrameHostManager::IsCurrentlySameSite to return true when |candidate->GetSiteInstance()| hosts the hosted app and |dest_url| is a same-site webpage outside of the hosted app's extent.  This is tricky, because the very first thing that SiteInstance::IsSameWebSite does is ask the //chrome layer for GetEffectiveURL.  I've tried removing GetEffectiveURL from extensions layer (i.e. from ChromeContentBrowserClientExtensionsPart) in https://codereview.chromium.org/2851763003 (note dependency on the other CL) but so far this hsa resulted in quite a few broken browser tests...

(*)
--- a/chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
+++ b/chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
@@ -88,7 +88,6 @@ namespace {
 // sure URLs are served by hosts with the right set of privileges.
 enum RenderProcessHostPrivilege {
   PRIV_NORMAL,
-  PRIV_HOSTED,
   PRIV_ISOLATED,
   PRIV_EXTENSION,
 };
@@ -147,7 +146,7 @@ RenderProcessHostPrivilege GetPrivilegeRequiredByUrl(
   if (extension && AppIsolationInfo::HasIsolatedStorage(extension))
     return PRIV_ISOLATED;
   if (extension && extension->is_hosted_app())
-    return PRIV_HOSTED;
+    return PRIV_NORMAL;
   return PRIV_EXTENSION;
 }
 
@@ -166,7 +165,7 @@ RenderProcessHostPrivilege GetProcessPrivilege(
     if (extension && AppIsolationInfo::HasIsolatedStorage(extension))
       return PRIV_ISOLATED;
     if (extension && extension->is_hosted_app())
-      return PRIV_HOSTED;
+      return PRIV_NORMAL;
   }
 
   return PRIV_EXTENSION;

Let's make this bug again focused only on --top-document-isolation and the follow-up for --site-per-process and other isolation modes can be tracked in issue 718516.

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

commit 0311d114732b87f41f80d839c0170cd68c364c10
Author: lukasza <lukasza@chromium.org>
Date: Fri May 05 15:40:48 2017

Disable top-document-isolation if the parent SiteInstance is a hosted app.

BUG= 679011 

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

[modify] https://crrev.com/0311d114732b87f41f80d839c0170cd68c364c10/chrome/browser/chrome_content_browser_client.cc
[modify] https://crrev.com/0311d114732b87f41f80d839c0170cd68c364c10/chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc
[modify] https://crrev.com/0311d114732b87f41f80d839c0170cd68c364c10/chrome/browser/extensions/chrome_content_browser_client_extensions_part.h
[modify] https://crrev.com/0311d114732b87f41f80d839c0170cd68c364c10/chrome/browser/ui/extensions/hosted_app_browsertest.cc
[add] https://crrev.com/0311d114732b87f41f80d839c0170cd68c364c10/chrome/test/data/frame_tree/cross_origin_but_same_site_frames.html
[add] https://crrev.com/0311d114732b87f41f80d839c0170cd68c364c10/chrome/test/data/frame_tree/simple.htm

I think it is okay to mark this bug as fixed and follow-up on the remaining issues in issue 718516.