IIUC, we create a |speculative_render_frame_host_| for the same site navigation inside the parent process. This however gets cleaned up after before unload handler fails. The clean up calls LocalFrame::Detach inside the parent which leads to Document::Shutdown and this line of code:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Document.cpp?rcl=5620d24a32541ef1f1a393112abef3ea66e396ed&l=2733

which would set the EmbeddedContentView of the owner element (which is at the time RemoteFrameView of the OOPIF) to nullptr. This causes the frozen-like behavior.

This is similar to plugin bugs I am fixing to I am marking this as a blocker for those.

I have a CL under review:
https://chromium-review.googlesource.com/c/chromium/src/+/898028.

This bug exists in M64 as well.

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

commit 73fedd040c60dbae15d97bf93926b7d577750821
Author: Ehsan Karamad <ekaramad@chromium.org>
Date: Tue Feb 06 21:23:01 2018

Fix an issue with speculative frame cleanup in OOPIFs

When the beforeunload handler is ACKed by the OOPIF process with "do not
proceed", the corresponding speculative frame is cleaned up. When the
speculative frame is in the parent frame's process it will set the
EmbeddedContentView of the owner element to nullptr. This is incorrect
as the navigation has been canceled.

This CL will avoid setting the EmbeddedContentView to nullptr when the
ContentFrame() is not equal to Document::GetFrame() (i.e., speculative)
and also the EmbeddedContentView is a RemoteFrameView.

Bug: 578349,  673170 ,  807772 
Change-Id: Ic6f5a16ae6f02bfbe11238851936ee323472a407
Reviewed-on: https://chromium-review.googlesource.com/898028
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Ehsan Karamad <ekaramad@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534795}
[modify] https://crrev.com/73fedd040c60dbae15d97bf93926b7d577750821/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/73fedd040c60dbae15d97bf93926b7d577750821/third_party/WebKit/Source/core/dom/Document.cpp
[modify] https://crrev.com/73fedd040c60dbae15d97bf93926b7d577750821/third_party/WebKit/Source/core/exported/WebFrame.cpp
[modify] https://crrev.com/73fedd040c60dbae15d97bf93926b7d577750821/third_party/WebKit/Source/core/frame/LocalFrame.h
[modify] https://crrev.com/73fedd040c60dbae15d97bf93926b7d577750821/third_party/WebKit/Source/core/frame/WebLocalFrameImpl.cpp

Thanks for the investigation and fix!  I can confirm this is fixed in 66.0.3342.0.

Ehsan, do you think this would be safe to merge to M65?

No problem! I believe it should be safe. The fix is quite small. I'll add the label just in case.

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

Pls merge your change to M65 branch 3325 ASAP so we can pick it up for next M65 Beta release. Thank you.

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

commit 36e80ec89c398f2832a252fe47d2f50c50ef38e6
Author: Ehsan Karamad <ekaramad@chromium.org>
Date: Thu Feb 08 20:20:42 2018

Fix an issue with speculative frame cleanup in OOPIFs

When the beforeunload handler is ACKed by the OOPIF process with "do not
proceed", the corresponding speculative frame is cleaned up. When the
speculative frame is in the parent frame's process it will set the
EmbeddedContentView of the owner element to nullptr. This is incorrect
as the navigation has been canceled.

This CL will avoid setting the EmbeddedContentView to nullptr when the
ContentFrame() is not equal to Document::GetFrame() (i.e., speculative)
and also the EmbeddedContentView is a RemoteFrameView.

TBR=ekaramad@chromium.org

(cherry picked from commit 73fedd040c60dbae15d97bf93926b7d577750821)

Bug: 578349,  673170 ,  807772 
Change-Id: Ic6f5a16ae6f02bfbe11238851936ee323472a407
Reviewed-on: https://chromium-review.googlesource.com/898028
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Ehsan Karamad <ekaramad@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#534795}
Reviewed-on: https://chromium-review.googlesource.com/909297
Cr-Commit-Position: refs/branch-heads/3325@{#390}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/36e80ec89c398f2832a252fe47d2f50c50ef38e6/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/36e80ec89c398f2832a252fe47d2f50c50ef38e6/third_party/WebKit/Source/core/dom/Document.cpp
[modify] https://crrev.com/36e80ec89c398f2832a252fe47d2f50c50ef38e6/third_party/WebKit/Source/core/exported/WebFrame.cpp
[modify] https://crrev.com/36e80ec89c398f2832a252fe47d2f50c50ef38e6/third_party/WebKit/Source/core/frame/LocalFrame.h
[modify] https://crrev.com/36e80ec89c398f2832a252fe47d2f50c50ef38e6/third_party/WebKit/Source/core/frame/WebLocalFrameImpl.cpp