Just to update, able to login directly by providing valid credentials.
Issue exists when selecting gmail.com/Google+ and sign-in with registered gmail id.

marking as RB beta, as this is impacting one of top site in India, please change if not required.

So far I can't repro on Mac canary 66.0.3334.0.  When I try to follow the steps using a personal gmail test account, I seem to log in successfully, the login popup closes (as in expected.mp4), and I'm taken to a page on my.naukri.com, which says "An account with email <foo@gmail.com> has not been created yet. Let us help you to create an account quickly."  It doesn't get stuck in the popup like in the repro.  Does the repro require a certain kind of account to already be registered with this site?

Note that the feature that's flipped to enable-by-default in https://chromium.googlesource.com/chromium/src/+/3b60933b099bba43823b2c5cbdbe7c3f2e90ae68 has already been enabled by default on all channels (M63+) via a Chrome field trial for more than a month.  Can you post your variations from chrome://version, from the version of Chrome where you're seeing this?

Also, can you check if your problem goes away if you run Chrome with --disable-features=sign-in-process-isolation?

M65 Beta promotion is coming soon and your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix and request a merge to M65 branch 3325 ASAP (merge has to be done latest by this Friday, 02/02 @ 5:00 PM PT). Thank you.

OK, I've finally reproed on Mac Canary 66.0.3334.0.  This is a problem with sign-in isolation (see issue 739418).  I had to do two things to repro:
- disable any other site isolation modes.  Specifically, the site isolation enterprise policy I was using isolated youtube.com, which makes this bug go away.
- before going to naukri.com, ensure that you're *signed out* from the google account you use.  If you're signed in, the login works correctly.

The latter also provides a crude workaround for this issue: clicking on the login button the second time actually works correctly, and the user gets logged in.

Here's what's going on.

After clicking "Login" and then the Google button, naukri.com opens a popup which goes to accounts.google.com to authenticate.  Once the user types in their credentials, the page navigates to 

[1] https://accounts.google.com/CheckCookie?hl=en&checkedDomains=youtube&checkConnection=youtube%3A134%3A1&chtml=LoginDoneHtml&service=lso&continue=https%3A%2F%2Faccounts.google.com%2Fsignin%2Foauth%2Fconsent%3Fauthuser%3Dunknown%26part%3DA...

Which does a server redirect to 

[2] https://accounts.youtube.com/accounts/SetSID?ssdc=1&sidt=ALWU2cuXrKj0VSL8p7PqQpNq8B3biSfxneRRLTVeS6k%2Bo1CL1cSVpM%2F3sBz1PN09nflY0MOOYX%2BdNrWPq5yxtoWZT2pq%2FGu5o8OLVHZ0EKr4a5HDCWqxivHsXrn95ap%2B%2BtOcLrHcnX1TJ2vbNrU%2B7IJ0ET1PYbfWBS659rIuEbqkJDvyolbChWGQBa8wHmMVL30Pi%2Bd9i7AswJApaNOIBtZ9ncI2jmZPR41dDG6amcAk88vs4%2BfSdQ3EHqFfm2xXrpPsBu2PWY7WSunMrAPyRuHlO0SUmlerQQ%3D%3D&continue=https%3A%2F%2Faccounts.google.com%2Fsignin%2Foauth%2Fconsent%3Fauthuser%3D0%26part%3DA...

Which commits at that URL.  At this point, because we've just transitioned from accounts.google.com, which requires a dedicated process, the popup went into a "youtube.com" SiteInstance.
 
Next, it looks like that accounts.youtube.com page does a client-side redirect back to accounts.google.com, to this URL:

[3] https://accounts.google.com/signin/oauth/consent?authuser=0&part=AJi8h...

Which does a server redirect to 

[4] https://login.naukri.com/nLogin/CallbackController.php?state=source%3Dg%26&code=4%2F9F2qYqa4-nZb9qExeAAGpmO20HFyPVzOg-FBzKS91as#

In the last navigation, the initial navigation to [3] will create a speculative RFH and a new process, but we'll throw that away in WillRedirectRequest, because there we'll decide that since we are currently on a site that does not require a dedicated process (youtube.com, from [2]), going to another site that does not require a dedicated process (login.naukri.com from [4]), that navigation can stay in the existing youtube.com SiteInstance and process.  Thus, the last navigation to login.naukri.com commits without ever going through DetermineSiteInstanceForURL, which would've discovered that this URL is same-site with the opener and should be going back to the opener's SiteInstance.  We end up with the popup on login.naukri.com in a youtube.com SiteInstance, and the opener in a naukri.com SiteInstance, and a script in the popup fails when it tries to script window.opener.

This is similar to  issue 796912 , except that the workaround there doesn't work here, due to accounts.youtube.com being cross-site from the opener (naukri.com).

The fact that this doesn't repro if the account used in the popup is already signed in is probably because in that case, there's no hop to accounts.youtube.com/accounts/SetSID.

+msarda@ for question about accounts.google.com below

On the Chrome side, the right fix here is to fix issue 787576, and we're making progress on that issue and its prerequisites.  For a shorter-term, mergeable fix, one option would be to generalize the workaround in DetermineSiteInstanceForURL, so that a frame goes back to the opener's SiteInstance not only if it's same-site with the opener, but also if neither frame requires a dedicated process.

I'm also surprised that this hasn't been discovered earlier, since as I mentioned, sign-in isolation has been on by default on all channels since mid-December, and this likely affects M64 stable as well (I can't confirm at the moment though).  msarda@: Is it possible that something on accounts.google.com changed recently in how it does redirects to/from accounts.youtube.com?  If the navigation to URL [4] were a client redirect instead of server redirect, this issue would go away.  Similarly, if URL [2] didn't commit but instead server-redirected to [3], we wouldn't have this issue.  Also, is the hop to accounts.youtube.com always part of this flow, or gated behind something?

+  abdulsyed@, manoranjanr@, PTAL comment #6 by alexmos@ (this likely affects M64 stable as well (I can't confirm at the moment though)

Just confirmed that this happens on Mac stable 64.0.3282.119 as well.  Doesn't happen when passing --disable-features=sign-in-process-isolation.

Since this has been present since M63 (mid-december) and it's affecting users using site isolation (smaller %), I am inclined to not block M64 stable release on this. However, I'd like to know how widespread is this issue and what other websites could be impacted? 

Alex: thoughts on whether this should block M64?

#9: This actually affects everyone, since site isolation of accounts.google.com launched in M63.  Opting into strict site isolation actually fixes this bug, as does specifying an enterprise policy that includes youtube.com (so, for example, Googlers won't see this bug).  I haven't tested, but I am pretty sure this would affect M63 users too.

I think we'll want to get input from someone on the sign-in side about #6 to know for sure whether this might affect other sites.  Specifically, how frequently is accounts.youtube.com navigated to in the OAuth flow, and did something recently change about the navigation/redirects in that flow that might've exposed more people to this bug, including M64 and M63 users.  So let's wait for thoughts from ewald@/msarda@ on this. 

If nothing recently changed on accounts.google.com, and nobody else has reported this during the last month, then it's more likely that it's not a widespread issue.

Note that there's one other report of a similar issue in  https://crbug.com/796912#c48 , which might have the same root cause.

Also, to clarify the scope of affected scenarios a bit more:

- this only affects users who try to complete the OAuth flow on a third-party site using a signed-out google account (which is probably relatively rare - I'd guess most people are already logged into gmail, etc.)

- when a user encounters this bug, if they try to log in again, the second attempt will likely work (because the account will already be signed in from the first try, and won't bounce through accounts.youtube.com), so there's already a "workaround".

- this only affects OAuth flows where the popup redirects to the opener's site after completing the flow, and then attempts to script the opener (or vice versa).  I don't know how common that pattern is, but, for example, using postMessage to pass auth data from popup to opener instead won't trigger this bug.

got it. Per #10, I think it makes sense to hold release now, until we have confirmation from sign-in team regarding full impact and scope (ewald@, msarda@).

We're following this up interanally over email with the Google Identity team.

Draft CL up at https://chromium-review.googlesource.com/c/chromium/src/+/894369

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

commit cd5b76ea43df36e2d64447aec0f5da654543133f
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Wed Jan 31 21:11:55 2018

Allow navigations to opener's site to go back into opener SiteInstance.

Previously, when a popup and its opener were cross-site, and neither
site required a dedicated process, navigating the popup back to the
opener's site did not swap processes, so the two ended up in different
processes and couldn't script each other.  Even though
DetermineSiteInstanceForURL contains logic to place same-site popups
into their opener's SiteInstance (added as part of the fix for a
similar  issue 796912 ), this logic was never reached because we never
attempted a process transfer in this case, thanks to
IsRendererTransferNeededForNavigation() returning false.

This CL tweaks IsRendererTransferNeededForNavigation so that a
cross-process transfer is always attempted is such cases.  This allows
DetermineSiteInstanceForURL to always place the popup that's going back
to its opener site into the opener's SiteInstance.

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

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

commit 39b7bef45a1837b0d2663e255e620494e5de766b
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Wed Jan 31 22:23:34 2018

Allow navigations to opener's site to go back into opener SiteInstance (Merge to canary branch)

Previously, when a popup and its opener were cross-site, and neither
site required a dedicated process, navigating the popup back to the
opener's site did not swap processes, so the two ended up in different
processes and couldn't script each other.  Even though
DetermineSiteInstanceForURL contains logic to place same-site popups
into their opener's SiteInstance (added as part of the fix for a
similar  issue 796912 ), this logic was never reached because we never
attempted a process transfer in this case, thanks to
IsRendererTransferNeededForNavigation() returning false.

This CL tweaks IsRendererTransferNeededForNavigation so that a
cross-process transfer is always attempted is such cases.  This allows
DetermineSiteInstanceForURL to always place the popup that's going back
to its opener site into the opener's SiteInstance.

TBR=alexmos@chromium.org

(cherry picked from commit cd5b76ea43df36e2d64447aec0f5da654543133f)

Bug:  807184 
Change-Id: Ia4d8d8b2107d3b9e3b9329dd473c06d49b7bd5ec
Reviewed-on: https://chromium-review.googlesource.com/894369
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#533410}
Reviewed-on: https://chromium-review.googlesource.com/896269
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/branch-heads/3335@{#6}
Cr-Branched-From: 94092b8f650d5552ed3595eb2b3a0a96488524e7-refs/heads/master@{#533164}
[modify] https://crrev.com/39b7bef45a1837b0d2663e255e620494e5de766b/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/39b7bef45a1837b0d2663e255e620494e5de766b/content/browser/isolated_origin_browsertest.cc
[modify] https://crrev.com/39b7bef45a1837b0d2663e255e620494e5de766b/content/browser/top_document_isolation_browsertest.cc

A couple of updates: 

lfg@ has helped confirm that this issue affects M63 as well.  (Thanks, Lucas!)

We've also identified that there was a change on accounts.google.com around Jan 8 which exposed this bug.

The current plan is to verify the fix from comment #15 on canary and then merge to M65 and M64.

Just verified that this fix is working on the latest canary build, 66.0.3335.5, 047e32ab68f20288b465d38ebd80808e811359fe-refs/branch-heads/3335@{#7}.  Requesting merge to M65 and M64.  Abdul and I already discussed the merge offline, but it should be safe: it's only a couple of lines and well-contained (affecting only cases where there's a popup and opener, they are in different processes, and the popup is navigating cross-site to the opener's site).

Approving merge for M64. Branch:3282
We will further check Canary tomorrow to ensure that this has not introduced any new crashes. However, confirmed with alexmos@ that this is a very safe merge.

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

commit 10c89a55822768262fbe92ea23e0f11909695b29
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Thu Feb 01 01:59:44 2018

Allow navigations to opener's site to go back into opener SiteInstance (Merge to M64)

Previously, when a popup and its opener were cross-site, and neither
site required a dedicated process, navigating the popup back to the
opener's site did not swap processes, so the two ended up in different
processes and couldn't script each other.  Even though
DetermineSiteInstanceForURL contains logic to place same-site popups
into their opener's SiteInstance (added as part of the fix for a
similar  issue 796912 ), this logic was never reached because we never
attempted a process transfer in this case, thanks to
IsRendererTransferNeededForNavigation() returning false.

This CL tweaks IsRendererTransferNeededForNavigation so that a
cross-process transfer is always attempted is such cases.  This allows
DetermineSiteInstanceForURL to always place the popup that's going back
to its opener site into the opener's SiteInstance.

TBR=alexmos@chromium.org

(cherry picked from commit cd5b76ea43df36e2d64447aec0f5da654543133f)

Bug:  807184 
Change-Id: Ia4d8d8b2107d3b9e3b9329dd473c06d49b7bd5ec
Reviewed-on: https://chromium-review.googlesource.com/894369
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#533410}
Reviewed-on: https://chromium-review.googlesource.com/896969
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#630}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/10c89a55822768262fbe92ea23e0f11909695b29/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/10c89a55822768262fbe92ea23e0f11909695b29/content/browser/isolated_origin_browsertest.cc
[modify] https://crrev.com/10c89a55822768262fbe92ea23e0f11909695b29/content/browser/top_document_isolation_browsertest.cc

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

commit b93dd95fa1f62402067f9ab5e8ad112c399e071d
Author: Trent Apted <tapted@chromium.org>
Date: Thu Feb 01 03:22:41 2018

Revert "Allow navigations to opener's site to go back into opener SiteInstance."

This reverts commit cd5b76ea43df36e2d64447aec0f5da654543133f.

Reason for revert: Suspected for persistent failures on linux-chromeos-rel. 4 cycles starting:

https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-rel/4806

PrerenderBrowserTest.PrerenderWindowSize fails with

../../chrome/browser/prerender/prerender_browsertest.cc:1084: Failure
Value of: DidDisplayPass(web_contents)
  Actual: false
Expected: true

(under NavigateToURLImpl(..))

Original change's description:
> Allow navigations to opener's site to go back into opener SiteInstance.
> 
> Previously, when a popup and its opener were cross-site, and neither
> site required a dedicated process, navigating the popup back to the
> opener's site did not swap processes, so the two ended up in different
> processes and couldn't script each other.  Even though
> DetermineSiteInstanceForURL contains logic to place same-site popups
> into their opener's SiteInstance (added as part of the fix for a
> similar  issue 796912 ), this logic was never reached because we never
> attempted a process transfer in this case, thanks to
> IsRendererTransferNeededForNavigation() returning false.
> 
> This CL tweaks IsRendererTransferNeededForNavigation so that a
> cross-process transfer is always attempted is such cases.  This allows
> DetermineSiteInstanceForURL to always place the popup that's going back
> to its opener site into the opener's SiteInstance.
> 
> Bug:  807184 
> Change-Id: Ia4d8d8b2107d3b9e3b9329dd473c06d49b7bd5ec
> Reviewed-on: https://chromium-review.googlesource.com/894369
> Reviewed-by: Charlie Reis <creis@chromium.org>
> Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#533410}

TBR=creis@chromium.org,alexmos@chromium.org

Change-Id: Iabdd81f6a5dc75795985074684e6be77c462a398
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  807184 
Reviewed-on: https://chromium-review.googlesource.com/896663
Reviewed-by: Trent Apted <tapted@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533545}
[modify] https://crrev.com/b93dd95fa1f62402067f9ab5e8ad112c399e071d/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/b93dd95fa1f62402067f9ab5e8ad112c399e071d/content/browser/isolated_origin_browsertest.cc
[modify] https://crrev.com/b93dd95fa1f62402067f9ab5e8ad112c399e071d/content/browser/top_document_isolation_browsertest.cc

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

commit 46a28e9a0b7d81141609bee53efa3dc89c08c836
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Thu Feb 01 06:11:51 2018

Reland "Allow navigations to opener's site to go back into opener SiteInstance."

This is a reland of cd5b76ea43df36e2d64447aec0f5da654543133f.

PrerenderBrowserTest.PrerenderWindowSize still failing after revert.

Original change's description:
> Allow navigations to opener's site to go back into opener SiteInstance.
>
> Previously, when a popup and its opener were cross-site, and neither
> site required a dedicated process, navigating the popup back to the
> opener's site did not swap processes, so the two ended up in different
> processes and couldn't script each other.  Even though
> DetermineSiteInstanceForURL contains logic to place same-site popups
> into their opener's SiteInstance (added as part of the fix for a
> similar  issue 796912 ), this logic was never reached because we never
> attempted a process transfer in this case, thanks to
> IsRendererTransferNeededForNavigation() returning false.
>
> This CL tweaks IsRendererTransferNeededForNavigation so that a
> cross-process transfer is always attempted is such cases.  This allows
> DetermineSiteInstanceForURL to always place the popup that's going back
> to its opener site into the opener's SiteInstance.
>
> Bug:  807184 
> Change-Id: Ia4d8d8b2107d3b9e3b9329dd473c06d49b7bd5ec
> Reviewed-on: https://chromium-review.googlesource.com/894369
> Reviewed-by: Charlie Reis <creis@chromium.org>
> Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#533410}

TBR=alexmos@chromium.org

Bug:  807184 , 807821
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I7808cef9292ff069bcfdd00fe71883d321d7f577
Reviewed-on: https://chromium-review.googlesource.com/897262
Commit-Queue: Trent Apted <tapted@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533588}
[modify] https://crrev.com/46a28e9a0b7d81141609bee53efa3dc89c08c836/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/46a28e9a0b7d81141609bee53efa3dc89c08c836/content/browser/isolated_origin_browsertest.cc
[modify] https://crrev.com/46a28e9a0b7d81141609bee53efa3dc89c08c836/content/browser/top_document_isolation_browsertest.cc

Rechecked the above issue on OS: 
Windows (7,8,8.1,10),Linux (14.04 LTS),Mac OS X(10.12.6,10.13.1,10.13.3) with stable chrome version:64.0.3282.140  and the issue works as intended.
Kindly refer attached screen cast for reference.

Thank you!

Deleted: Stable 64.0.3282.140 verified.mp4 999 KB

	Stable 64.0.3282.140 verified.mp4 999 KB View Download

Rechecked the above issue on OS: 
Windows (7,8,8.1,10),Linux (14.04 LTS),Mac OS X(10.12.6,10.13.1,10.13.3) with chrome version:66.0.3335.5  and the issue works as intended.
Kindly refer attached screen cast for reference.

Note:Issue is still reproducible on latest canary #66.0.3336.0.

Thank you!

Deleted: 66.0.3335.5 verified.mp4 1.1 MB

	66.0.3335.5 verified.mp4 1.1 MB View Download

#24: Thanks for verifying!  Yes, it appears that the latest 66.0.3336.0 canary does *not* have my fix from #15 (it was cut at r533409, just one revision short of the fix which is r533410), but the 66.0.3335.5 canary, to which I manually merged in #16, does have it.

Interestingly, I noticed that in your case, accounts.google.com redirected to accounts.google.co.in/accounts/SetSID instead of accounts.youtube.com like in my own repro.  This would have triggered the same issue; I guess depending on account you may be redirected to a different set of domains where it's necessary to set SID cookies.

Adding missing label, as I think this affects CrOS too.

Approving merge to M65 branch 3325 based on comments #18 and #23. Please merge ASAP. Thank you.

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

commit e31d27377b58924c4126fe6f5142403432b31456
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Thu Feb 01 19:37:54 2018

Allow navigations to opener's site to go back into opener SiteInstance (Merge to M65)

Previously, when a popup and its opener were cross-site, and neither
site required a dedicated process, navigating the popup back to the
opener's site did not swap processes, so the two ended up in different
processes and couldn't script each other.  Even though
DetermineSiteInstanceForURL contains logic to place same-site popups
into their opener's SiteInstance (added as part of the fix for a
similar  issue 796912 ), this logic was never reached because we never
attempted a process transfer in this case, thanks to
IsRendererTransferNeededForNavigation() returning false.

This CL tweaks IsRendererTransferNeededForNavigation so that a
cross-process transfer is always attempted is such cases.  This allows
DetermineSiteInstanceForURL to always place the popup that's going back
to its opener site into the opener's SiteInstance.

TBR=alexmos@chromium.org

(cherry picked from commit cd5b76ea43df36e2d64447aec0f5da654543133f)

Bug:  807184 
Change-Id: Ia4d8d8b2107d3b9e3b9329dd473c06d49b7bd5ec
Reviewed-on: https://chromium-review.googlesource.com/894369
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#533410}
Reviewed-on: https://chromium-review.googlesource.com/898063
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#241}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/e31d27377b58924c4126fe6f5142403432b31456/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/e31d27377b58924c4126fe6f5142403432b31456/content/browser/isolated_origin_browsertest.cc
[modify] https://crrev.com/e31d27377b58924c4126fe6f5142403432b31456/content/browser/top_document_isolation_browsertest.cc

Able to repro on 65.0.3325.39/10323.12.0 dev-channel Kip device and on 66.0.3329.36/10366.0.0 dev-channel Paine device.
There is no latest build on Chrome OS available with the fix.
and will verify this issue once the build with the fix is available.

Thanks..!!

Verified the issue on CrOS on 65.0.3325.56/10323.17.0 dev channel Kip,Daisy,Reks and issue is fixed.

Thanks!

Rechecked the above issue on OS: 
Windows (7,8,8.1,10),Linux (14.04 LTS),Mac OS X(10.12.6,10.13.1,10.13.3) with chrome version:65.0.3325.52  and the issue works as intended.
Kindly refer attached screen cast for reference.

Deleted: Verified 65.0.3325.52.mp4 4.2 MB

	Verified 65.0.3325.52.mp4 4.2 MB View Download

Google Chrome	66.0.3352.0 (Official Build) dev (64-bit)
Platform	10431.0.0 (Official Build) dev-channel