Able to reproduce the issue on Windows 10, mac 10.12.6 and Ubuntu 14.04 using chrome reported version #63.0.3239.132 and latest canary #65.0.3312.0.
Note: At ET-Hyd, the issue is not reproducible in chrome reported version #63.0.3239.132 and reproducible on latest canary #65.0.3312.0, but consistently reproducible by inhouse team. hence, providing the bisect results.

Bisect Information:
=====================
Good build: 63.0.3239.67    
Bad Build : 63.0.3239.74    
Note: The chrome builds between .67 and .74 did not launch. Good and bad range are branch builds. Hence, providing the manual bisect and CL from omahaproxy.

Change Log URL:(From Omahaproxy) 
https://chromium.googlesource.com/chromium/src/+log/63.0.3239.67..63.0.3239.74?pretty=fuller&n=10000

From the above change log suspecting below change
Change-Id: I28578bfd7f141ea8bdf0330f2342a1fb77619148
Reviewed-on: https://chromium-review.googlesource.com/786276

lukasza@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Note: Adding stable blocker for M-63 as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

Please check attack gif

Deleted: reservationdesk.gif 11.9 MB

	reservationdesk.gif 11.9 MB View Download

I can repro at the ToT (at r527268 to be precise).  I cannot repro after launching chrome with --disable-features=sign-in-process-isolation.  This suggests that isolation of accounts.google.com is causing the problem.

kailash.soni@ could you please confirm that the issue goes away after launching Chrome with --disable-features=sign-in-process-isolation cmdline flag?

+ewald@ and alexmos@ - we need to make a decision whether to keep the sign-in-process-isolation feature enabled on the stable channel.  Disabling the feature should "fix" this bug on the stable channel (although I note that manually isolating accounts.google.com or google.com [either via cmdline, via chrome://flags or via enterprise policy] will likely bring the bug back - this note seems important in light of the recommendation at https://support.google.com/faqs/answer/7622138#chrome)

Please note that the root cause is different from  issue 796912  (which had similar symptoms, but which is fixed on M63, starting from 63.0.3239.127).  This issue repros even on M65.

I'm investigating.  

This also happens in --site-per-process, so it's likely not specific to sign-in isolation (unlike  issue 796912 ), but rather a general problem with OOPIFs/cross-process navigations, though it happens to be triggered here by isolation of accounts.google.com.

It appears the OAuth flow completes successfully in a popup, after which it redirects the popup to a page on https://travelpass.hub.loginradius.com.  That page seems to do three things in its inline script:
1. Set window.top.location to something on https://travelpass.hub.loginradius.com (That's just going to navigate itself - not sure why it does that.)
2. Set window.opener.location to something on https://travelpass.hub.loginradius.com (this is likely the step that fails -- the opener isn't navigated in the repro.)
3. Calls window.close().

It appears that with --site-per-process or sign-in isolation, this actually doesn't *always* fail -- I had one successful login in several attempts.  However, when I disabled window.close() in my local build as an experiment, so the popup doesn't go away, the login succeeds consistently.  So there's some sort of race here: the popup being closed is interfering with navigating the opener, and step 1 might be interfering as well.

Quick update:

- Navigating the opener in step 2 is a cross-process navigation which happens via the proxy, and in the repro, RenderFrameProxyHost::OnOpenURL does get called in the browser process and correctly creates the NavigationRequest.

- This NavigationRequest then gets destroyed via the following stack as part of processing window.close():

#2 0x7f71f51405fe content::NavigationRequest::~NavigationRequest()
#3 0x7f71f51213eb content::FrameTreeNode::ResetNavigationRequest()
#4 0x7f71f514d998 content::RenderFrameHostImpl::OnRenderProcessGone()
#5 0x7f71f514d534 _ZN3IPC8MessageTI35FrameHostMsg_RenderProcessGone_MetaNSt3__15tupleIJiiEEEvE8DispatchIN7content19RenderFrameHostImplES8_vMS8_FviiEEEbPKNS_7MessageEPT_PT0_PT1_T2_
#6 0x7f71f514cc17 content::RenderFrameHostImpl::OnMessageReceived()
#7 0x7f71f5364f90 content::RenderProcessHostImpl::ProcessDied()
#8 0x7f71f5364ae8 content::RenderProcessHostImpl::FastShutdownIfPossible()
#9 0x55ee1f4bc9d2 CloseWebContentses()
#10 0x55ee1f4b7230 TabStripModelImpl::InternalCloseTabs()
#11 0x55ee1f4b746f TabStripModelImpl::CloseWebContentsAt()
#12 0x55ee1f48969b chrome::CloseWebContents()
#13 0x7f71f537557a content::RenderViewHostImpl::OnClose()
#14 0x7f71f5375396 _ZN3IPC8MessageTI22ViewHostMsg_Close_MetaNSt3__15tupleIJEEEvE8DispatchIN7content18RenderViewHostImplES8_vMS8_FvvEEEbPKNS_7MessageEPT_PT0_PT1_T2_
#15 0x7f71f5374af9 content::RenderViewHostImpl::OnMessageReceived()

It seems closing the popup WebContents incorrectly decides to blow away the process even though it has a pending navigation in another (opener) WebContents.

For #11, here's a slightly more informative stack from a debug build on how the NavigationRequest gets destroyed:

#3 0x7f28579bf7d9 content::NavigationRequest::~NavigationRequest()
#4 0x7f28579673c5 content::FrameTreeNode::ResetNavigationRequest()
#5 0x7f2857a31528 content::RenderFrameHostManager::CancelPendingIfNecessary()
#6 0x7f28579e0d49 content::RenderFrameHostImpl::OnRenderProcessGone()
#7 0x7f2857942d74 _ZN4base20DispatchToMethodImplIPN7content20FileAPIMessageFilterEMS2_FviiENSt3__15tupleIJiiEEEJLm0ELm1EEEEvRKT_T0_OT1_NS6_16integer_sequenceImJXspT2_EEEE
#8 0x7f2857942ca8 _ZN4base16DispatchToMethodIPN7content20FileAPIMessageFilterEMS2_FviiENSt3__15tupleIJiiEEEEEvRKT_T0_OT1_
#9 0x7f2857942c37 _ZN3IPC16DispatchToMethodIN7content20FileAPIMessageFilterEMS2_FviiEvNSt3__15tupleIJiiEEEEEvPT_T0_PT1_OT2_
#10 0x7f2857a01393 _ZN3IPC8MessageTI35FrameHostMsg_RenderProcessGone_MetaNSt3__15tupleIJiiEEEvE8DispatchIN7content19RenderFrameHostImplES8_vMS8_FviiEEEbPKNS_7MessageEPT_PT0_PT1_T2_
#11 0x7f28579df0ad content::RenderFrameHostImpl::OnMessageReceived()
#12 0x7f2857f69585 content::RenderProcessHostImpl::ProcessDied()
#13 0x7f2857f68bea content::RenderProcessHostImpl::FastShutdownIfPossible()
#14 0x55b786862827 CloseWebContentses()
#15 0x55b786855655 TabStripModelImpl::InternalCloseTabs()
#16 0x55b7868558f8 TabStripModelImpl::CloseWebContentsAt()
#17 0x55b7867e542f chrome::CloseWebContents()
#18 0x55b7867b5bc1 Browser::CloseContents()
#19 0x7f2858299e95 content::WebContentsImpl::Close()
#20 0x7f2857f9a4a7 content::RenderViewHostImpl::ClosePageIgnoringUnloadEvents()
#21 0x7f2857f9b6ff content::RenderViewHostImpl::OnClose()

It seems the root cause here is that RenderProcessHostImpl::FastShutdownIfPossible() allows the process to shut down even though it has a pending navigation (pending_views_ count is 1).  It currently only checks for active views, but not pending ones:

  if (page_count && GetActiveViewCount() != page_count)
    return false;

Also checking pending_views_ here makes this bug go away.  (In the repro, page_count is 1, GetActiveViewCount() is 1, and pending_views_ is also 1.)

Thanks for quickly determining the root cause, Alex.

In terms of next steps: what's the plan for --site-per-process? Were we planning to roll that out more widely in M64?

Also, is there a way for us to tell how severe this bug is? If we were to land the fix and merge it to 64, would it be reasonable to live with the behavior that gets triggered by having --sign-in-process-isolation enabled for the rest of 63?

To clarify my question about severity: this only affects certain sites that handle OAuth login in a particular way, correct? It's not all sites that use Google's OAuth login system?

#16: That's correct.  This requires a particular structure with two sites other than the OAuth site.  Basically, you have to start at site A, which opens the OAuth popup, which redirects the popup to site B, which then navigates the original (opener) window from A to B while simultaneously closing the popup.  This might cause the A->B navigation to get dropped.  (The intention is to eventually redirect back to A in the original window)

kailash.soni@: Until we get this issue fixed, would it be feasible for you to work around this issue by waiting for the opener navigation before closing the popup?

I.e., right now, in the popup where you log in, you get redirected to a page like https://travelpass.hub.loginradius.com/socialauth/validate.sauth?code=xxxxxxxx# , which does the following:

                window.top.location = 'https://travelpass.hub.loginradius.com/success.aspx?token=xxxxxxx&callback=https://www.reservationdesk.com/login-radius-authentication/';
                if(window.opener){
                    window.opener.location = 'https://travelpass.hub.loginradius.com/success.aspx?token=xxxxxxx&callback=https://www.reservationdesk.com/login-radius-authentication/';
                }
                window.close();

A workaround might be to replace the window.close() above with something that waits for opener to load your success.aspx page.  Something like:

function closePopup() {
  try {
    if (opener.location.href.startsWith("https://travelpass.hub.loginradius.com/success.aspx"))
      window.close();
  } catch (e) { 
    // opener.location.href will throw an exception until opener becomes same-origin with this window.
    setTimeout(closePopup, 10);
  }
}

and then replace your window.close() call above with a call to closePopup().  

It's not great, but would something like this be feasible in the short term?  (You might also need to deal with your window.top.location navigation, which might interfere.)

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

commit bb77f012cbc8a13c0a6ac40af221debb1d02fe8a
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Sun Jan 07 19:39:39 2018

When closing a tab, do not shut down its process if it has pending views from other tabs.

Currently, RenderProcessHostImpl::FastShutdownIfPossible() only checks
the active view count when deciding whether to allow shutdown.  In
addition, it should also check whether there are any pending views
(from other tabs).

This fixes an issue where a tab foo.com opens a popup bar.com, which
then navigated its opener to bar.com and immediately closes itself via
window.close().  Doing so should not shut down the bar.com process and
let the pending navigation in the opener tab complete.

Bug:  799399 
Change-Id: I19bfdfa0340cea726bb436ddf1568f08e50ef443
Reviewed-on: https://chromium-review.googlesource.com/852982
Commit-Queue: Charlie Reis <creis@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527543}
[modify] https://crrev.com/bb77f012cbc8a13c0a6ac40af221debb1d02fe8a/chrome/browser/chrome_site_per_process_browsertest.cc
[modify] https://crrev.com/bb77f012cbc8a13c0a6ac40af221debb1d02fe8a/content/browser/renderer_host/render_process_host_impl.cc

r527543 made it into canary 65.0.3315.0, and I've just verified that this issue is fixed there - I can successfully login to reservationdeck.com with a Google account.  Requesting merge to M64.  This should be low risk, as it's a one-line change, and already verified in canary.

Thanks for the quick fix Alex! Approved

branch:3282

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

commit 22355da7439db0171a29eee95a565d7381ad20bc
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Mon Jan 08 19:27:38 2018

When closing a tab, do not shut down its process if it has pending views from other tabs (Merge to M64)

Currently, RenderProcessHostImpl::FastShutdownIfPossible() only checks
the active view count when deciding whether to allow shutdown.  In
addition, it should also check whether there are any pending views
(from other tabs).

This fixes an issue where a tab foo.com opens a popup bar.com, which
then navigated its opener to bar.com and immediately closes itself via
window.close().  Doing so should not shut down the bar.com process and
let the pending navigation in the opener tab complete.

TBR=alexmos@chromium.org

(cherry picked from commit bb77f012cbc8a13c0a6ac40af221debb1d02fe8a)

Bug:  799399 
Change-Id: I19bfdfa0340cea726bb436ddf1568f08e50ef443
Reviewed-on: https://chromium-review.googlesource.com/852982
Commit-Queue: Charlie Reis <creis@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#527543}
Reviewed-on: https://chromium-review.googlesource.com/854768
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#448}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/22355da7439db0171a29eee95a565d7381ad20bc/chrome/browser/chrome_site_per_process_browsertest.cc
[modify] https://crrev.com/22355da7439db0171a29eee95a565d7381ad20bc/content/browser/renderer_host/render_process_host_impl.cc

Please request merge to M63

Also, for #25, I've just confirmed that this fix works as intended on my local M63 branch.

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

commit 57f3b7bf2e57539b928669c3ae6765a5f932d3da
Author: Alex Moshchuk <alexmos@chromium.org>
Date: Mon Jan 08 22:14:06 2018

When closing a tab, do not shut down its process if it has pending views from other tabs (Merge to M63)

Currently, RenderProcessHostImpl::FastShutdownIfPossible() only checks
the active view count when deciding whether to allow shutdown.  In
addition, it should also check whether there are any pending views
(from other tabs).

This fixes an issue where a tab foo.com opens a popup bar.com, which
then navigated its opener to bar.com and immediately closes itself via
window.close().  Doing so should not shut down the bar.com process and
let the pending navigation in the opener tab complete.

TBR=alexmos@chromium.org

(cherry picked from commit bb77f012cbc8a13c0a6ac40af221debb1d02fe8a)

Bug:  799399 
Change-Id: I19bfdfa0340cea726bb436ddf1568f08e50ef443
Reviewed-on: https://chromium-review.googlesource.com/852982
Commit-Queue: Charlie Reis <creis@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#527543}
Reviewed-on: https://chromium-review.googlesource.com/854784
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#717}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/57f3b7bf2e57539b928669c3ae6765a5f932d3da/chrome/browser/chrome_site_per_process_browsertest.cc
[modify] https://crrev.com/57f3b7bf2e57539b928669c3ae6765a5f932d3da/content/browser/renderer_host/render_process_host_impl.cc

Can we mark this as fixed to TE can verify?

Marking as fixed.  The fix should be on canary and should reach M64 beta in a couple of days; M64 will go to stable in a couple of weeks.

kailash.soni@loginradius.com: please let us know if the workaround I suggested in #18 is not feasible for you in the meantime.