I am able to reproduce the sad tab on one of my iPhone6+ with 9.3.5
When I copy paste the link (Full URL) page is loading fine, but when I copy paste the goo.gl link its crashing (sadtab) immediately.
Firefox also showing similar behavior but not very consistently.

Checking on more configs for a consistent repro steps.

This is happening with any articles on medium.com including medium.com homepage.
I opened the home page, 
Background the app, Force quit Chrome and Relaunch
Repeat the above step 2 or 3times and on 3rd launch Aw,Snap page is displayed.

On FIrefox, Open medium.com home page and once the page is loaded completely, refresh the page two or three times, page goes blank.

Reproduces on Safari too just after one force quit.

Please let me know if you need any other information.

M-58 as this seems to be a recent regression (we're noticing it a lot more lately).

I saw this several times with other websites while I was flying (VirginAmerica was one). What are the next steps here? It's very jarring from a user perspective. Raising priority. 

I have not seen this on iPad, only on my phone. 

I am seeing this on Google SRP and on memegen. As I mentioned, this doesn't seem to be related to any particular website. 

Yes, I'm seeing it too. Sad to say, I haven't spent much time on this in the past few days.

This is probably a regression in Tab, where many refactorings has happened.

Assigning to Justin since pkl and rohit are out, and eugene is really busy.

Justin, please prioritize this for m58.

Our aw, snap started increasing steadily in M54: 
  https://uma.googleplex.com/p/chrome/timeline_v2?sid=0d8d3fddea2488d443b2353861e41f18

gchatz@ eugenebut@ pkl@ Any ideas what might cause this?  

Memory consumption increase by major web sites? Unfortunately we still don't know the page URL for renderer crashes.

Just fyi there is also this sad tab issue we're already tracking since M54: https://bugs.chromium.org/p/chromium/issues/detail?id=670453#c26

I can reproduce this pretty easily with all sorts of web pages, and showed it to justin today. All it took was backgrounding the app with a page (not NTP) in foreground, opening a bunch of apps (gmail, feedly, etc) and then opening Chrome. Boom, sad tab on foreground tab.

Sounds like there are 2 separate problems:
1.) Sad Tab is shown if app is in the background (this bug)
2.) Renderer crashes are reported more often (crbug.com/670453)

This bug is specifically about (1) because Chrome, at returning to foreground, is supposed to detect that the frontmost tab's renderer has been terminated and refresh the page w/o showing a sad tab.

I'm curious what happens when an app is suspended (not backgrounded, but actually suspended/paused by the OS, and com.apple.WebKit.WebContent::WebProcessProxy crashes, or basically all of Webkit.WebContent...

When restoring the app, I wonder if -webViewWebContentProcessDidTerminate gets called during or after foregrounding completes.

The theory in #16 appears to be correct, and testing shows an error in how we handle sad tab in this state.  This bug has always been there, so it's unclear why people are noticing it more.

Fix in flight: https://codereview.chromium.org/2782713002

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

commit e888fae6c93c60d14163109930ade47a0fec644a
Author: justincohen <justincohen@chromium.org>
Date: Mon Apr 03 16:47:04 2017

Correct UIApplicationState check for sad tab test.

Checking for the backgroundState isn't enough -- the app can be in the inactive
state.  Instead, just check for !active.

BUG= 701583 

Review-Url: https://codereview.chromium.org/2782713002
Cr-Commit-Position: refs/heads/master@{#461453}

[modify] https://crrev.com/e888fae6c93c60d14163109930ade47a0fec644a/ios/chrome/browser/tabs/tab.mm

Verified in M60, M59.0.3071.21 dev.
Verified by Backgrounding the app, killing WebKit.WebContent, launching the app.
App Launched correctly, reloaded the foremost tab without any SadTab errors.

Device: iPhone6plus, iOS: 10.1.1