I've been working on fixing some tab crash related tests and wanted to extend it with some e10s-multi cases as well, while experimenting with it I've found two issues. 1. When a content process of a bg tab crashes, we always reload the related tabs on next selection, while for the first selected tab we should display about:tabcrashed. 2. When a foreground tab crashes, and there is a same process tab among the pinned tabs, there is no restore all tabs button, and the related pinned tab does not get auto-reloaded either.

Mike, are my assumptions above correct about the expected behavior here?

Yep, that's correct - see bug 1241459 comment 16.

Per triage, this is WFM.

Mike, rereading your comment and the comment you referred to I'm a bit confused. Everybody agreed that what we have now is the behavior we should have for crashed bg tabs, and we will file another bug for the pinned tabs. But to me that contradicts your comment... just so I can sleep better, could you do me a favor and double check the behavior with multi real quickly? (should be simple, the pid is in the tooltip of the tabs thanks to Brad). Sorry for bothering you with this, I just want to make sure that this works as it's designed. The part I don't see happening is this: > The user eventually switches to one of the crashed tabs. Maybe it's B. Maybe > it's C. It doesn't matter - the result is the same: the user sees the > about:tabcrashed page.

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #4) > The part I don't see happening is this: > > The user eventually switches to one of the crashed tabs. Maybe it's B. Maybe > > it's C. It doesn't matter - the result is the same: the user sees the > > about:tabcrashed page. I'm guessing this is probably because you have browser.crashReports.unsubmittedCheck.autoSubmit set to true? If so, we never show about:tabcrashed for background tabs - we just send the crash reports straight away, and the browser is restored on demand.

(That last case is intentional, and tested here: http://searchfox.org/mozilla-central/rev/672c83ed65da286b68be1d02799c35fdd14d0134/browser/components/sessionstore/test/browser_background_tab_crash.js#148-169)

(In reply to Mike Conley (:mconley) from comment #5) > (In reply to Gabor Krizsanits [:krizsa :gabor] from comment #4) > > The part I don't see happening is this: > > > The user eventually switches to one of the crashed tabs. Maybe it's B. Maybe > > > it's C. It doesn't matter - the result is the same: the user sees the > > > about:tabcrashed page. > > I'm guessing this is probably because you have > browser.crashReports.unsubmittedCheck.autoSubmit set to true? If so, we > never show about:tabcrashed for background tabs - we just send the crash > reports straight away, and the browser is restored on demand. Uhh... That was it! Thanks, I was totally confused.