This is a regression in 63. 

Not related to interstitials.

This is happening on the regular pages as well. Aw Snap page is never displayed when the WebView crashes.
For example goto any of the pages below
1. https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
2. https://www.cnet.com/news/pixar-virtual-reality-coco-vr-land-of-the-dead/

Try to pinch zoom few times and scroll, and the webview will crash in sometime.
In M61 builds Aw,Snap page is displayed. but M62 and above only a blank page is displayed.

https://drive.google.com/file/d/120_3rvNz1nf0l9nskLN5CqzNPMaaNErs/view

Bisected the issue from comment#6 to below range:
Good version: 62.0.3202.68 #37951eb
Bad Version: 62.0.3202.69 #cb71dd0

There is also a difference between iOS 10.x and 11.x
Seems like on iOS 11, the renderer termination callback is not called.
Still researching.

Set to M64. It's unlikely that we will be able to address this in the very near term of M63.

For the specific issue of the Aw Snap page not showing up on iOS11, when RenderProcessGone() is properly called:

https://chromium-review.googlesource.com/c/chromium/src/+/727401 destroys the WKWebView after it crashes, to work around an iOS11 painting bug.  However, the Aw Snap page is added using "webState->ShowTransientContentView(contentView)".  I believe this means that the AwSnap page is a child of the web content view, and when we destroy the web content view, we also destroy the aw snap page.

The above would also explain the difference between iOS10 and iOS11, since the change was ios11-only.

It *does not* explain cases on 11.1 where we are allegedly seeing that RenderProcessGone() is not called at all.  That sounds like an iOS bug and should probably be split off into a different issue.

Could we rework the iOS11 fix to discard the WKWebView at the point where it is about to be reloaded, rather than right when it crashes?

The Aw Snap page should probably move out of //ios/web and up somewhere into //ios/chrome, but that's not likely to make 64 or 65.

The specific call chain that is causing issues is:

[CRWWebController webViewProcessDidCrash]
->[CRWWebController removeWebView]
  ->[CRWWebControllerContainerView resetContent]
    -> self.transientContentView = nil

Eugene will look at a fix for this.  He suggested calling |removeWebView| before installing the aw snap page, instead of after.

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

commit b06cdb885c0f2e80f469036d67ce6f782955240b
Author: Eugene But <eugenebut@google.com>
Date: Thu Nov 30 04:19:40 2017

Fixed Interstitial presentation for web view crash.

-[CRWWebController removeWebView] removes web, navite and interstitial
views. Which means that calling removeWebView after
OnRenderProcessGone() will immidiately remove interstitial added by
OnRenderProcessGone.

This CL changes the order of operations and calls removeWebView before
OnRenderProcessGone.

Bug:  781119 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I617ad6304e344289266e9462168e825a90d26dbe
Reviewed-on: https://chromium-review.googlesource.com/798055
Reviewed-by: Eugene But <eugenebut@chromium.org>
Reviewed-by: Kurt Horimoto <kkhorimoto@chromium.org>
Commit-Queue: Kurt Horimoto <kkhorimoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520432}
[modify] https://crrev.com/b06cdb885c0f2e80f469036d67ce6f782955240b/ios/web/web_state/ui/crw_web_controller.mm

+cmasso: Do we leave M63 as-is (without the fix in comment 20) and take this fix for M64 only?

[Auto-generated comment by a script] We noticed that this issue is targeted for M-64; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-64 label, otherwise remove Merge-TBD label. Thanks.

I don't think blank page instead of Sad Tab is a huge deal. The fix is also not extremely safe.

@pkl can you please comment on if this is still RBS M64 given comment 24 by Eugene?

Sorry for confusion. I think this should be Merged to M64. But not into M63.

Turns out the fix made M64 without cherry-pick.

Thanks for the update!!

Tested on 64.0.3282.14 Beta on iPhone8(iOS 11.2)

Aw snap page is now displayed when the WebView crashes, how ever the blank page is displayed when the same WebView is crashed again after relaunch i.e. the initial issue mentioned in comment#0 still exist. 

Steps: 
1. Launch chrome
2. Open web page https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
3. Try to pinch zoom few times and scroll, and the webview will crash in sometime. 
4. With out closing tab page, force quit and relaunch app
5. Repeat step 3

Observed result:
At step 3, Aw snap page is displayed
At step 5, blank page is displayed.

Link to video: 
https://drive.google.com/a/google.com/file/d/1Iebj33gnd2AwwhH4dZrHkYPzRBq_0BrK/view?usp=sharing

Steps from comment #30 are very different from steps in original bug description. Fix from comment #20 addresses only iOS 11 issue. Could you please file a separate bug with steps from comment #30 (this is a different bug and will require a different fix).

eugenebut@ Even steps from original bug report are still reproducible on M64.0.3282.14 beta and M65.0.87.0 canary.

Steps to reproduce: (From Comment#0)
1. Fresh install chrome and Launch chrome
2. Force quit chrome and relaunch 
3. In the tab page open chrome://crash

I still see a blank page after these steps.

Tested on iPhone7plus, with iOS11.2

M65.0.87.0 == M65.0.3287.0

Thanks srikanthg@. So I tested the app with http://browsingtest.appspot.com/venti.html and SadTab does not show up with 62.0.3202.68 #37951eb which is marked as a good version (comment #8). I'm not concerned with chrome://crash, bug because it does not affect the users, but not displaying SadTab for real renderer crash is a problem which we should fix. Generally chrome://crash should only be used for testing SadTab UI, because unlike on Desktop or Android, chrome://crash does not crash the renderer.

This is the reason why I asked to track problem from comment #31 separately. I agree that Fixed resolution is not correct for this bug. But as I said earlier, I'm less concerned about chrome://crash functionality (it's definitely not RBS).

Having said that, could you please file a bug for comment #30. You can use http://browsingtest.appspot.com/venti.html for testing the crashes.

srikanthg@, please see comment #34. 

There are 2 separate bugs here:
Bug from description and comment #32 is P3, because chrome://crash is not for end users
Bug from comment #30 is probably RBS, because it does affect end users

srikanthg@ or rakurati@, please file a separate bug for #30 and check if #30 is also a regression.

Thanks

To Summarise, here is what I understand so far:
Comment#30 and #32 are same issue only difference is they are using different webpages to in the repro case.
Before this bug fix --> We are not seeing Aw Snap pages at all anywhere, anysite.
After this bug fix --> We are now seeing Aw Snap if the webpage crashes on a newly opened tab. If any of the webpages from the existing tabs are crashed then AwSnap page is still not displayed, instead a blank page is displayed.

I am going close this bug as Fixed as now we are able to see the Aw Snap page whenever the renderer crashes.

I will create new bug now and link here shortly.

Another note: browsingtest/venti.html used to display AwSnap page in the past, but now with higher end devices like iPhone8, iPhoneX, iPad pro, this webpage renders fine all the times. So we can not depend on this page for all the devices testing. brendaneich.com/... is what reliably crashes when we pinch-zoom on any high end devices.

Tested with brendaneich.com. Revision #37951eb also has the bug (Sad Tab is not shown after relaunch).

Flipping to Available, because this is still a bug but P3. Please assign a new bug to me. Thanks!

Here it is: http://crbug/793161

Sergio, do you think this is related to crrev.com/c/651756 ?

Yes, looks like it! Once you force quit the app the newly created SadTabCoordinator by BVC is not assigned to already existing tab helpers. 

Looks like fixed by crrev.com/c/833231

Verified in M64.0.3282.85 beta
Device: iPhoneX
iOS: 11.2.5 beta#4