Unable to reproduce the issue on reporter chrome version 63.0.3239.108 and latest canary 65.0.3300.0 using Mac 10.13.1 with the steps mentioned below

Steps follwed to reproduce the issue:
1) Launched chrome reported version
2) Hosted the parent on `notmydomain.com`
3) Host the iframe on `mydomain.com`
4) It navigates to new window and that window shows the error message as "This site can’t be reached"

@Reporter:
Please find the attached screncast for your reference and let us know if we missed any steps in reproducing the issue
We have tried to reproduce the issue on reported version(63.0.3239.108) and 62.0.3202.94, in both the builds the behaviour is same, find the screencast attached and provide your inputs on this issue which help in further triaging the issue.

Thanks!

Deleted: 796912_62.0.3202.94.mp4 9.2 MB

	796912_62.0.3202.94.mp4 9.2 MB View Download

Deleted: 796912_63.0.3239.108.mp4 8.3 MB

	796912_63.0.3239.108.mp4 8.3 MB View Download

You need to actually host the files.
I use `npx` for this, like `npx http-serve -p 3500 -c -1`. (this has the benefit to host it on 127.0.0.1 and 192.168.x.x so you get 2 domains easily to test with)

The parent needs to load the iframe so you have an iframe in a document on another domain

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce this using the Google OAuth2 flow launched from an <iframe>.

Issue appears to be new in version 63 and fixed in versions 64-65.

Will this be fixed in version 63, or should we expect to wait until Chrome 64? This is a pretty big issue; we'd have to rearchitect our entire Google OAuth2 flow to deal with it.

Same here, added some local storage stuff as an extra layer but not nice and I would guess more people are having issues

Thanks for the report.  I strongly suspect this is a site isolation issue, and an instance of issue 787576.  The problem is likely due to the popup and the opener subframe ending up in separate processes.  I've confirmed it's happening for me using OAuth flow in a popup initiated from a cross-origin subframe on M63 (without --site-per-process), but not on M65.

For people that can repro this on M63, can you confirm whether this issue goes away if you run chrome (M63) with the --disable-features=sign-in-process-isolation flag?  And that when you can repro, the tab with the iframe and the popup end up in separate processes in Chrome's task manager?

Here's what I think is happening.  Suppose only site C requires a dedicated process.  Suppose you go to A embeds B: B stays in A's process and SiteInstance with the a.com site URL.  B opens a same-site popup, which also stays in that SiteInstance.  The popup navigates to C; this is a cross-process navigation that swaps to a new SiteInstance.  Then C navigates back to B.  This is also a cross-process navigation, but when it tries to determine the new SiteInstance, it doesn't find an existing one with b.com site URL (the original one that it's supposed to go to has the a.com site URL), so it creates a new SiteInstance and doesn't go back into the A process like it should.  In this case, C is the Google OAuth origin that the popup redirects to and then away from.

This also won't repro with --site-per-process, where the B subframe would swap into its own process and SiteInstance, and later the popup would correctly go back into it.

Now, here's why I believe it's fixed in M64 and M65.  I added the following logic into DetermineSiteInstanceForURL as part of fixing hosted apps for --site-per-process in r521188:

  if (frame_tree_node_->opener()) {
    RenderFrameHostImpl* opener_frame =
        frame_tree_node_->opener()->current_frame_host();
    if (IsCurrentlySameSite(opener_frame, dest_url))
      return SiteInstanceDescriptor(opener_frame->GetSiteInstance());
  }

This is a shortcut to use the opener's SiteInstance if the opener is same-site with the current frame.  It would fix the problem here by using the opener's SiteInstance (which has both A and B).  This was merged to M64, but not M63.

#9: Yes, we'll fix this for M63 one way or another.  Give us a few days to figure out the best way forward, and sorry about the breakage!

Another workaround you might consider in the meantime is sending a postMessage from your redirected popup to window.opener (which is the iframe in this case), and pass the new location.href over.  I believe that should still work.

Unable to reproduce this issue after trying with steps mentioned in comment#5 using Mac 10.13.1 with build #63.0.3239.108

1. In terminal changed to directory where the attached html files are present.
2. Gave npx http-serve -p 3500 -c -1 in terminal and navigated to http://127.0.0.1:3500 in browser and opened parent.html
3. Naviagted to http://10.59.222.66:3500 and opened iframe.html >> Allowed pop-up in blocker and observed"This site can't be reached" message

@Reporter: Could you please check the video and let us know if we miss anything. This would help in further triaging of the issue.

Thanks!

Deleted: 796912.mp4 1.3 MB

	796912.mp4 1.3 MB View Download

It looks like googleoauthflow.com is a placeholder for the an oauth flow. To reproduce one probably needs to stub out a page that when visited does a redirect to mydomain.com

Here's a repro which should work on M63, using three test sites instead of OAuth.

1. Start Chrome with --isolate-origins=https://alexmos17.github.io --disable-features=site-per-process

2. Go to http://csreis.github.io/tests/cross-site-iframe.html

3. Click "Go cross-site (simple page)"

4. Right-click and inspect the cross-site iframe.

5. Execute the following:
var w = window.open();
w.location.href = "https://alexmos17.github.io"; // swaps processes
w.location.href = "https://csreis.github.io";    // does not swap back to parent process

6. At this point, the popup is same-site with the iframe, but the iframe can't script it:

w.location.href
VM179:1 Uncaught DOMException: Blocked a frame with origin "https://csreis.github.io" from accessing a cross-origin frame.
    at <anonymous>:1:12
(anonymous) @ VM179:1

even though "document.origin" returns "https://csreis.github.io" in the iframe.

Here, "https://alexmos17.github.io" is used as an isolated origin instead of the OAuth origin. 

The same repro can also work from the main frame, *if* there was a preceding cross-site navigation in that main frame that stayed in the same process prior to opening the popup.  E.g., starting at http://csreis.github.io, set location.href = "https://csreis.github.io" and then do step 5.

Just to ask again, can someone experiencing this issue with OAuth please confirm whether the issue goes away if you launch Chrome with --disable-features=sign-in-process-isolation?

Happy to see someone who seems to have reproduced this. Here's what I've learned: 1. The reproduction case given by the reporter is incomplete. 2. I have created a reproduction case that seems to do what my application does, but I can't yet get it to fail. I'll compare it to what's given in comment 17. I will also try the test indicated in comment 18.

Yes, in reply to comment 18, I can confirm that the problem does not manifest in our application when running with --disable-features=sign-in-process-isolation on the command line.

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

commit d65e9a9652d053c2c2f91535e5d3258a27355dfc
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Wed Dec 27 23:27:56 2017

Add same-site scripting tests for some cases involving isolated origins.

This CL adds tests for the following cases:

1. A cross-site iframe opens a popup, which then navigates to an
isolated origin and then back to the opener iframe's site.  The opener
iframe and the popup should be able to script each other, as they are
same-site.  This mimics some OAuth flows.

2. In an ABA hierarchy with B being an isolated origin, the root and
grandchild frames should be able to script each other.

The logic to handle these cases already exists in M64 and M65; this CL
updates the comment for it to clarify that it is also used for these
cases.

Bug:  796912 
Change-Id: Ia441e230ec036235c24d2007b314b7768570174f
Reviewed-on: https://chromium-review.googlesource.com/845126
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#526252}
[modify] https://crrev.com/d65e9a9652d053c2c2f91535e5d3258a27355dfc/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/d65e9a9652d053c2c2f91535e5d3258a27355dfc/content/browser/isolated_origin_browsertest.cc

alexmos@ has a CL that merges the relevant part of the r521188 fix to M63 in https://chromium-review.googlesource.com/c/chromium/src/+/845014.  It includes some new tests for this case specifically, which we just landed on trunk in r526252.  The full fix has been baking on M65 and M64 for a while as part of issue 718516, and this subset of it should be safe to merge to M63 as well.

Requesting permission to merge https://chromium-review.googlesource.com/c/chromium/src/+/845014 to M63.

Approving https://chromium-review.googlesource.com/c/chromium/src/+/845014 to merge for M63. Branch:3239

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

commit 4932e1113f2cd31de54ec491e470b41922db42b7
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Thu Dec 28 17:30:03 2017

Merge fix for leaving same-site iframes in opener or main frame process to M63.

This CL extract a small change from r521188 to avoid putting same-site
iframes, where one is either the other frame's opener or main frame,
in different processes, after navigations from an isolated origin.
r521188 is available on M64 and M65, whereas this fix is intended
to be merged to M63.

Bug:  796912 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I0af759bf3009741425a5556bd31a26dd3e87b791
Reviewed-on: https://chromium-review.googlesource.com/845014
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#700}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/4932e1113f2cd31de54ec491e470b41922db42b7/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/4932e1113f2cd31de54ec491e470b41922db42b7/content/browser/isolated_origin_browsertest.cc

 Issue 797026  has been merged into this issue.

Alex, should we update our Finch config to only turn it on for 100% on 63 for people that get whatever the new respin of 63 will be with this fix included?

For those of us who are not experts on the Chromium release process, when should we expect a Google Chrome 63 build containing this fix to arrive with users? Thanks, and if there's a better place to ask, let me know!

Comment 26: I think that's a good idea.  We should update the field trial to require the M63 version with the fix as soon as we can, so that the bug goes away regardless of how long the new build takes to go out.  (We don't yet have an ETA for the new build.)

Sorry for not giving a super complete test case, this is my first Chromium bug report and for something I am not an expert on.
Thank you for helping and taking a look at this!
Am I correct that there is a fix and it will land in the M63 version at one point?

#29: Yes, this will be fixed on M63 soon.  We'll post an update here once that happens, hopefully tomorrow if all goes well.

Awesome ✨

This should now be fixed on M63.  Restarting Chrome should make things work again.

We've temporarily disabled the sign-in isolation feature that was causing this until the next M63 update, which will have the proper fix in place.

Note that until that update goes out, this bug would still be possible on M63 if you manually turned on --site-per-process ("strict site isolation" from chrome://flags, or via enterprise policy), or specify --isolate-origins for google.com or accounts.google.com.

Correction to #32: this actually won't affect --site-per-process users, only --isolate-origins users.

Amazing, thanks for fixing this 🚀

Issue 797144 has been merged into this issue.

Verified this issue on Mac OS 10.12.6, Windows-10 and Ubuntu 14.04 using chrome latest stable #63.0.3239.132 by following steps mentioned in the comment #17. Observed the popup now shows in the same process as the first tab under task manager and "https://csreis.github.io/" is displayed in the console with out any DOM exception error. Hence adding TE-Verified label for M63.

Thanks! 

Deleted: 63.0.3239.84.png 210 KB

	63.0.3239.84.png 210 KB View Download

Deleted: 63.0.3239.132.png 172 KB

	63.0.3239.132.png 172 KB View Download

Thanks for the quick action on this!

Just to be clear, merely restarting the browser (but not updating it) is sufficient to fix this issue, and no new build is needed? In other words, this broken feature has been essentially remotely disabled through some process where the browser contacts the server for configuration information?

Correct - restarting Chrome is sufficient to fix the issue.  Restarting Chrome will reset the set of active Variations visible in chrome://version - in particular the 1bced4a3-... variation should now be disabled in Chrome versions earlier than 63.0.3239.127).

PS. Note that 63.0.3239.127 and later include a fix (see #c24 above) for this bug and therefore will again enable the 1bced4a3-... variation.

Also - apologies for the breakage.  Normally we avoid enabling new features just before the holidays freeze period, but we decided to make an exception for some Site Isolation features, as Site Isolation mitigates some variants of the recently disclosed Spectre attack - see https://www.chromium.org/Home/chromium-security/site-isolation and https://support.google.com/faqs/answer/7622138#chrome

Chrome 63.0.3239.132 - which includes this fix - was pushed to stable yesterday.

Verified the issue on Chrome OS(Reks device) using latest stable 63.0.3239.140/10032.86.0 by following steps mentioned in the comment #17. Issue seems to be working fine. Attaching screenshot for reference.

Deleted: VerifiedIssue.png 131 KB

	VerifiedIssue.png 131 KB View Download

Hello Guys,

I have tested on chrome 64.0.3282.119 (Official Build) (64-bit) (cohort: 64_119_win). I can still see this issue.

anyone else facing same issue?

#45: I've just retested the problematic scenario in 64.0.3282.119, and it works for me.  I've tried steps in comment #17, as well as OAuth-based steps on a local server:
- start on a page a.com that embeds iframe on b.com
- inspect the iframe, and execute var w = window.open() in it.
- in the new popup, set up and click a "Sign in with Google" button, which redirects to accounts.google.com to log in.
- after logging in, it redirects to b.com with the OAuth token.
- from the opener iframe, check w.location.href.  It can be accessed properly.

Can you comment on how your setup differs from this?  If you check Chrome's task manager, do you see that the opener and popup tabs end up in different processes?

This fix was actually available on stable since 63.0.3239.132.  Did you check your scenario in that version by any chance?

Hi, I reply to comment #46, I have attached the recording about this problem, it is an oauth authentication, it route back to the same domain as parent window but the parent window still not able to talk to the popup. We found out this problem happen when the new flag "Strict site isolation" is DISABLED. We enable it then the problem is gone.

Deleted: 20180129_125219.mp4 2.6 MB

	20180129_125219.mp4 2.6 MB View Download

nintexkj@: Are there repro steps we could try to repro the problem ourselves?  The video in #c48 definitely helps confirm that there is a problem, but unfortunately I wasn't able to infer from the video how to attempt to repro myself.

The fact that the problem goes away when Strict Site Isolation is enabled seems to suggest that the root problem might be another flavour of issue 787576.  We hoped that the fixes in M63 and M64 (looking at opener and parent of frames when determining their target process) would be sufficient for most flavours of issue 787576 - having repro steps (and knowing the exact frame relationships) would help us figure out if a short-term fix for another flavour might be needed and/or possible.

PS. Based on the above, I am guessing that the issue might also go away when running Chrome with --disable-features=sign-in-process-isolation.  It might be useful to confirm that.

Note: there's a similar report in  issue 807184 , and we have a lead on what's going on there.  I'm hoping that the issue seen in #48 is a variant of that issue, but we can confirm once we have the fix for  issue 807184  ready.

#50:
I have tested it in version 64.0.3282.140 and works without any issue.

Thanks :)