here is test case (extension)

Deleted: testcase.zip 160 KB

testcase.zip 160 KB Download

Thanks for filing.  I can confirm that the issue repros on Mac canary 65.0.3288.0 (with --site-per-process, but that's not required for this repro).  

After enabling chat by pressing "c", I opened https://www.twitch.tv/directory/game/Fortnite in a new tab, and a command-shift click from there on any live channel results in a black area where the chat OOPIF is supposed to be.  I also noticed that switching to another tab and then back always seems to fix it - the chat OOPIF appears after switching back.  So that's one workaround.

I also noticed that command-click and then switching to the tab always seems to load the OOPIF properly, but *shift*-command-click (which opens the new tab as focused) does not.

This seems like an OOPIF visibility issue, though I couldn't repro it with --site-per-process and our regular test pages.

Actually, there is a super-simple repro:

1. Start chrome with --site-per-process.
2. Go to https://csreis.github.io/tests/
3. From DevTools, window.open("http://csreis.github.io/tests/cross-site-iframe-simple.html")

Expected: the iframe in the new tab loads and shows "Before you may cross the bridge..."

Actual: the iframe remains blank, even though it shows up in Task Manager.

So, with A-opens-B(A2), we are somehow not making A2 visible.  Also works if A2 is created dynamically (as is the case with twitch.tv).  Cycling through tabs fixes it.

I haven't found the cause yet after digging a bit.  We create the subframe's RWHVCF in CreateRenderFrame and immediately Hide() it, then at commit time we Show() it and send a WasShown to the widget.  The widget updates its visibility state to kVisible on the renderer side and seems to call SetNeedsBeginFrame(), but I don't see any matching compositor frames arriving on the browser side (i.e., no calls to RWHI::SubmitCompositorFrame() for the subframe's widget).  Ken, any ideas on what might cause this?  Also +ekaramad@ who's looked at some similar issues in the past (e.g., in r495861).

Here's a quick test that repros this (by timing out):

IN_PROC_BROWSER_TEST_F(SitePerProcessBrowserTest,
                       OpenPopupWithSubframeInOpenerOrigin) {
  GURL main_url(embedded_test_server()->GetURL("a.com", "/title1.html"));
  EXPECT_TRUE(NavigateToURL(shell(), main_url));

  Shell* popup_shell =
      OpenPopup(shell()->web_contents(), GURL(url::kAboutBlankURL), "popup");

  GURL popup_url(embedded_test_server()->GetURL(
      "b.com", "/cross_site_iframe_factory.html?b(a)"));
  EXPECT_TRUE(NavigateToURL(popup_shell, popup_url));

  FrameTreeNode* popup_subframe =
      static_cast<WebContentsImpl*>(popup_shell->web_contents())
          ->GetFrameTree()
          ->root()
          ->child_at(0);
  WaitForChildFrameSurfaceReady(popup_subframe->current_frame_host());
}

Thank you Alex for the test cases! I did look into this a bit and haven't figured out the root cause. But I found out that if we never hide the RenderWidgetHostViewMac of the popup the test passes (I am Mac but I suspect this is the case for other platforms as well). To simulate this I early returned at RWHVMac::Hide().

I ran a bisect on Mac and this seems to be the final range:

https://chromium.googlesource.com/chromium/src/+log/e888fae6c93c60d14163109930ade47a0fec644a..ad78154afec04a34cbdb091309102bd5292b0906

Could it be 00cf940 (Revert "Destroy the old RenderWidgetHostView when swapping out a main frame." by piman) combined with the recent changes by alexmos@ in swapped out state of RVH?

I also ran a bisect on Linux but got a different range: https://chromium.googlesource.com/chromium/src/+log/a8531dcdee790985eb8f87daa9256c5c907b141f..94cbc4321c3a084b7417325dee296dc4843808b5

Out of those four CLs, the likely culprit is lfg@'s r403176, Fire visibilityChange event on out-of-process iframes.  Lucas: would you have any time to look at this?  I know it's been a long time since that CL, and if you won't be able to take a look, feel free to reassign it back to me or Ehsan and we'll keep looking at it.

Ehsan, I'm curious if your Mac bisect might've been off by any chance?  Might be worth repeating to make sure, in case this also involves a Mac-specific regression?

Hmm, I guess we see different regression ranges because "mean-value theorem" promises finding _a_ root :)!

So I did run another bisect for the range between CL right after the regression range you found and the one  right before the one I reported -- looking for the CL that fixed it. I am seeing this range for it:
https://chromium.googlesource.com/chromium/src/+log/7fde98c771cafc15ea4d5c8018084b5cd64d3200..9431efdc7b0146ef74f75ce160f2ba343ca2d550

The suspect fix would be Lucas's CL perhaps?
" Destroy the old RenderWidgetHostView when swapping out a main frame" https://codereview.chromium.org/2496233003

So so far, most probably scenario seems to be the r403176 regressed it, then r438516 fixed the regression, and then again r461459 re-regressed it. This is of course assuming those of the culprits and then we do not have any more regressions and fixes in between :).

Re #8, #9: You're all correct :)

This is a duplicate of  issue 638375 .

Also, to the original reporter, you can use rel=noopener as a workaround to this issue, as mentioned in  issue 638375 .

lfg@ , this workaround is not applicable for my case.

Re#12: Your extension already injects content scripts inside twitch.tv, you'd have to modify the <a> links that opens the channels to include rel=noopener in the presence of ctrl+shift modifiers or middle-clicks. It's annoying to do, but not impossible.

I don't expect this bug to be fixed in the very short term, so it'll be at least a few quarters before we can fix this in Chrome, as we need to fix a more fundamental issue first (splitting RenderView/RenderWidget).

lfg@ , my current workaround is to wait 1 second after page load before creating the <iframe>.

i am using location.replace() instead of <a> clicks, because i need to replace the web page with my extension's page.