In Bug 899348 we implemented a first draft of a tab crashed page for Desktop. The priority here is relatively low, because we don't ship Electrolysis. Bug 913155 has some design discussion especially about the "submit crash-report" feature. There was some mockup for Firefox OS that could be relevant: http://people.mozilla.com/~lco/Crash_Reporting_B2G/R1_Crash%20Reports%20v1.pdf.

adding Zhenshuo because I think we have opportunity to align this with the crash UX in general

Needs mockups.

User Advocacy would love to be involved in any discussions around improving the crash UX so feel free to include Matt and I in this process.

Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".

Move old M2 P3 bugs to M4 (because tracking-e10s=m5+ flag doesn't exist yet).

Hey mmaslaney, just wanted to loop you into something that the e10s team talked about yesterday. Currently, when single-process Firefox crashes, by default we attempt to reload the crashed session - we bring back all of the tabs (which might only actually start loading once selected), to get the user back to their pre-crash state ASAP. If, however, the same conditions that caused the crash still exist in the restored tabs, and we crash again, we change tack a little bit, and display the "this is embarrassing" page which allows the user to select which windows and tabs they restore. We _might_ want to do something similar with tab crashes - like, if we crash a bunch of tabs, we should attempt to restore them on the first go - but if we crash again, we might want to consider showing an interface that allows users to selectively restore tabs - otherwise, they risk getting caught in some kind of crash loop.

User Flow: http://people.mozilla.org/~mmaslaney/e10s/FX-e10s-v1.png Thanks for the feedback, Conley. I've worked the "first attempt reload" and window/tab management into the user flows. Let me know your thoughts. Pinging Philipp for a UX review.

(In reply to mmaslaney from comment #9) Suggestions: 1. Definitely use the exclamation badge. The other solution is too similar to Chrome's implementation. 2. Grayscale the crashed tab's site favicon, and make it clear that the red badge is an overlay. 3. The "Send crash report" button is nice, but it's better to offer the user to view the report first before sending it away (if the user decides to). Not everybody is comfortable with sending any personal or statistic data somewhere, even if they are anonymous. And some people might just wish to know why the crash happened and/or try to troubleshoot it. 4. Tab crashing is a serious event, so when that happens, some sort of little notifying effect would be nice. Consider "popping" the badge up into existence (in a similar manner toolbarbuttons do in Customization mode upon grabbing). 5. In the mockup, the address bar of the crashed tab is empty. It's important to know which tab crashed, and tab title is often not enough. 6. Make the "Reload" button a default action (make it blue or whatever) to stand out more. 7. Add a resizer to the Tabs to restore table (in case some titles are too long).

Hint: At the moment most (all?) of the content tabs are rendered from the same process - which means if one of the tab crashes all of the other tabs crash as well. This face should be indicated to the user by e.g. displaying the exclamation badge or the crash-smily icon for every tab that was tied to the same process that has crashed.

I think Option 2 is a better icon to display in the tab as it does not overwrite the identity of the tab, and it's easier for a user to scan and see what site has crashed. Mr. Crash is great to display in the body though. I agree with jaramat above that the URL should remain in the URL bar, and that the reload button should stand out more. Same with the Restore button in screen four. Would the "Send crash report" just open up the crash reporter window, or directly send the report? If the former, maybe instead of saying "Send crash report" which implies that the report is being sent immediately, it could just say "Crash Reporter". If the later, we should offer a way to see some of the details. Otherwise ui-review+ on this pending these couple changes!

For the crash reporting, I think the current check box approach is much better. We really want to get as many crash reports as possible. Most people will just click the Reload button and then we'll never get a crash report.

Some additional feedback: I do indeed like Mr. Crashtab. :) I'm happy with the exclamation mark favicon, and pretty much everything sevaan remarked on. I'm worried about two things: 1) Crash reports are critical for us to ensure that the content process remains as stable as possible. If a user has opted to provide crash reports in Data Choices, we should probably default the behaviour to submit a crash report if the user restores or starts a new session. I'm thinking instead of a link to send a crash report, we expose a checkbox that reflects the user's choice under Data Choices. If they've chosen to submit crash reports, then the checkbox defaults to checked to submit one regardless of which button they press. There are additional things that we usually want from crash reports too. I've attached a screenshot of our current crash report interface. Note the ability to include a comment about what the user was doing, the ability to include (or exclude) the URL that the user was on, as well as a contact address. There's also a "details" button to show more information about the crash. I know that's a _ton_ of stuff to cram in there, and we might want to hide some of it by default, or re-think how we want to include it - but that stuff is definitely important to crash reports. Feel free to ask me more questions about crash reports. :) 2) The multiple tab / window case is a little tricky. Remember that in that case, we haven't actually closed the browser windows or tabs that have caused the crash - they're all still hanging out there in the background. So are they all displaying this interface? What happens if I choose to restore a subset of those tabs? I suppose the rest go back to state 3? That makes sense to me. Also, the list of tabs needs to include which windows they're belonging to - each tab should have a window parent. See: http://i.imgur.com/CK8bT2X.png Feel free to ask me for more information about this stuff.

Updated mocks per Michael and Sevaan's feedback: http://people.mozilla.org/~mmaslaney/e10s/FX-e10s-v2.png Notable changes to include • Using an error badge over the site's favicon for crash notifications • Exposing the crash reporting checkbox • Added "Restore all tabs" button for high volume tab crashes

(In reply to mmaslaney from comment #15) > Updated mocks per Michael and Sevaan's feedback: > http://people.mozilla.org/~mmaslaney/e10s/FX-e10s-v2.png Overall like this iteration! What is the default behavior we expect most users to do based on the three buttons "Close tab", "Restore Tab" and "Restore all tabs"? Personally I think "Restore all tabs" or "Restore Tab" is what people like to do most of the time. However, in the current mockup the button "Close tab" stands out as it is the only one with a different color. Is this intended or should one of the "Restore" buttons get the gray background color (or maybe even both?).

I agree with Julian, it seems weird to have two highlighted buttons. I assume this logo is of course not final, but I would wish we could come up with something cuter, and a bit different from the Youtube icon, our plugin crashed icon and Chromes icon.

I think the proposed workflow of this iteration works well. Brain-dump: In the first iteration of e10s we're likely to ship, we're going to have just a single content process, so if that process goes down, _all_ tabs in e10s windows go into the crashed state. That's going to piss folks off, but that's one of our baby-steps to getting to multiple content processes. I suggest we make "Restore all tabs" our default highlighted option to get people back on their feet. HOWEVER In the event that we've crashed yet again (or even several times) very soon after hitting "Restore all tabs", I wonder if we should change the emphasis to the "Restore this tab" button, to encourage the user to restore just the tabs that they need to function for now. Of course, this last case will not be necessary for users that have the "load tabs when selected" pref set to true, as even if they restore all tabs, a "tab that will crash" will not cause the crash until we select it. Hopefully the above is a useful contribution to this conversation.

One thing that I didn't fully understand here is the behavior on a first crash. Is the idea that, on a first crash, we will attempt to reload all tabs, without any user intervention? If that's the case, what's the plan to let users submit the reports for these crashes?

(In reply to :Felipe Gomes from comment #19) > One thing that I didn't fully understand here is the behavior on a first > crash. Is the idea that, on a first crash, we will attempt to reload all > tabs, without any user intervention? If that's the case, what's the plan to > let users submit the reports for these crashes? The way I understood it, the first crash will show the tab crashed page as mmaslaney has laid it out. I think I'm muddying the waters with my comment in comment 18 - I just want to make sure we do what we can to prevent the user from getting into a loop where they restore all tabs, and crash again, and restore all tabs, and crash again, etc. The current spec gives us the escape hatch of letting us restore individual tabs anyways, so it's just a matter of emphasis. But maybe that's something to worry about more down the line.

Speaking of muddying the waters, mmaslaney and I just chatted in IRC, and it looks like I missed reading part of the spec. The current spec has the user get all of their tabs loaded automatically on a crash immediately, without user intervention. I think we don't want to do that - we want to show the tab crash UI after the first crash, and let the user choose to restore that tab, all tabs, or close the tab (along with submitting a crash report). I think that's what felipe was alluding to in comment 19.

Updated: http://people.mozilla.org/~mmaslaney/e10s/FX-e10s-v3.png Changes: • Removed the 1st reloading step • Based on Conley's tab crash comments (line 18), I have decided to make "Restore all tabs" the default action.

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #21) > The current spec has the user get all of their tabs loaded automatically on > a crash immediately, without user intervention. I think we don't want to do > that - we want to show the tab crash UI after the first crash, and let the > user choose to restore that tab, all tabs, or close the tab (along with > submitting a crash report). Showing the crash-page on the first crash-time to the user has two disadvantages to me: 1. it's very obvious to the user that we crashed - maybe we can have a way to make this less obvious to the user and don't punch them into their face that Firefox is buggy ;) 2. the user has to stop it's work flow because of the crash and click one of the buttons like "Restore All Tabs" 3. having the ability to reload individual tabs is nice - but I am not sure the average user will understand that a tab is crashing over and over again and what exactly the difference between restore all and just a single tab is. Also, for the user it might be wired to understand this scenario anyway - s/he was doing something on one page (aka. tab) and now all the other completely isolated tabs are crashed as well - why are they related? (Once you understand the technical implementation is is very clear, but I doubt the average user does this^^) To fix 1) and 2) I think it's better to reload all tabs automatically. This will distract the workflow a little bit but not as much as if the user sees a crash page. Still I think it's good to notify the user that there was a crash and has them to send crash information. Maybe there could be a bubble (like the one if Nighly users want to turn e10s on by default) that notifies the user about the crash and asks him to send crash reports (also including a "never ask me this again" option). In terms of 3) I think it's better to use a heuristic: If a page causes the content process to crash very frequently then don't reload the page by default but ask the user explicit using a full-page notification like the ones in the current mocks. I also wonder: do we know which tab causes the crash of the content process?

Also since the Tracking protection has landed on Nightly and we can block part of a page, we could do some basic troubleshooting on a tab's crash. Like we could (somehow) determine what was the cause of the crash (some script? A plugin? Misbehaving add-on?) and block the script/plugin/add-on from loading/running. And of course display a notification to the user. Is this even possible?

(In reply to Julian Viereck from comment #23) > 1. it's very obvious to the user that we crashed - maybe we can have a way > to make this less obvious to the user and don't punch them into their face > that Firefox is buggy ;) On the flipside, when Firefox crashes pre-e10s it's very obvious because the whole browser goes down. You already have to make a conscious effort to start the process again, so you probably don't want to be greeted with the 'oops' page unless it's happening over and over again. In e10s, on the other hand, it seems like there would be no manual action required, which might be pretty confusing. If the pre-crash state we saved is incomplete or otherwise not up-to-date, and the user doesn't realize a crash occurred (because he/she wasn't looking at the time, let's say), it would be pretty off-putting to suddenly see some of your work lost without any explanation of what happened. In addition, unfortunately it can be very hard to get the attention of people not used to working with computers - any kind of dropdown notification or bar might well be missed, leaving the user confused. A full page UI, on the other hand, is unmissable, and seems like it would be closer to "Where did Firefox go? Oh, it crashed".

(In reply to jaramat from comment #24) > Also since the Tracking protection [...] > > Is this even possible? No. In general we can't usefully diagnose the reason for a crash client-side. And tracking protection is unrelated to this bug, let's please keep this on topic. Generally the issues have been around basically (1) UX to explain/indicate to the user that a problem occurred, (2) how to get the user back into their flow with minimal hassle and (3) how to encourage the user to opt-in to reporting the problem via our crash reporting mechanisms. The historical tension has been between 2 and 3. We need crash reports to improve the browser, but that can be privacy-sensitive so it's opt-in. /cc bsmedberg, since he's been involved in past app/plugin crash work.

Comments on mmaslaney's screenshots: * Is there a reason that the comment/email section is closed by default? The comments are in general one of the most-valuable things we have for diagnosing crashes that aren't perfectly obvious, and I'd like to highlight that rather than hide it by default. * Wouldn't "Reload" be better than "Restore" here? That is in effect what we are doing * "Restore all tabs" should be "Reload all crashed tabs", since it's possible there will be tabs which haven't crashed. I also feel that the other button should be "Reload this tab" just to make the distinction clear. * We also need a variation of the design in the case where the user has already submitted the crash report, in this kind of scenario: ** user has two tabs open, A/B running in the same process ** the content process crashes (both tabs are crashed) ** The crash-report checkbox is checked and the user user chooses "reload this tab" in tab A ** Tab B should now no longer have the option to submit the crash report (since it's already submitted) but perhaps have some "Crash report already submitted; thank you for helping make Firefox better!" text.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #27) > * Wouldn't "Reload" be better than "Restore" here? That is in effect what we > are doing I don't understand this; I assume we're actually restoring using sessionrestore rather than simply reloading, and "restore" is a better description of that.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #27) > Comments on mmaslaney's screenshots: > > * Is there a reason that the comment/email section is closed by default? The > comments are in general one of the most-valuable things we have for > diagnosing crashes that aren't perfectly obvious, and I'd like to highlight > that rather than hide it by default. > I think mmaslaney is attempting to strip away noise from the tab. Good to know that comments are one of the most valuable bits - I wasn't aware of that. > * Wouldn't "Reload" be better than "Restore" here? That is in effect what we > are doing > > * "Restore all tabs" should be "Reload all crashed tabs", since it's > possible there will be tabs which haven't crashed. I also feel that the > other button should be "Reload this tab" just to make the distinction clear. I agree with gavin that "restore" more accurately describes what is happening here - but yes, "Restore all crashed tabs" even _more_ accurately describes what that button does. :) > > * We also need a variation of the design in the case where the user has > already submitted the crash report, in this kind of scenario: > ** user has two tabs open, A/B running in the same process > ** the content process crashes (both tabs are crashed) > ** The crash-report checkbox is checked and the user user chooses "reload > this tab" in tab A > ** Tab B should now no longer have the option to submit the crash report > (since it's already submitted) but perhaps have some "Crash report already > submitted; thank you for helping make Firefox better!" text. Good point!

Are we in fact restoring from session-restore in this case? That will probably require an additional implementation bug, unless there's work I'm not aware of. When a plugin crashes and we prompt to reload, we definitely don't currently use session-restore.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #30) > Are we in fact restoring from session-restore in this case? That will > probably require an additional implementation bug, unless there's work I'm > not aware of. When a plugin crashes and we prompt to reload, we definitely > don't currently use session-restore. Work for that is being tracked in bug 1065785.

Does it make sense to try to make the UI as similar as possible between the existing crash reporter dialog (for whole process crashes) and the content process UI? Your proposed UI is not terribly different than the existing UI, but you're using a different icon and different text. Am I off the mark here?

Thanks for the feedback, everyone V4: http://people.mozilla.org/~mmaslaney/e10s/Firefox-e10s-v4.png Couple updates while we wait for copy: • Changed the language in the buttons to read "Restore this tab" and Restore all crashed tabs" • Exposed the crash report fields based on their relative importance • Created a variation of the design in the case where the user has already submitted the crash report

(In reply to Tom Schuster [:evilpie] from comment #17) > I assume this logo is of course not final, but I would wish we could come up > with something cuter, and a bit different from the Youtube icon, our plugin > crashed icon and Chromes icon. Are there any attempts to change the "Mr. Crash" logo? In Germany many YouTube music videos are blocked and the displayed icon on YouTube looks very similar [1]. As an idea: instead of showing a worried Mr. Crash could we use a image of a tab that is broken in the middle? [1]: http://en.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany#mediaviewer/File:YouTube_blocked_Germany_GEMA_en.png

I'm not sure how much whimsy and attitude we want to go for here, but I tried to follow the example of the existing page and came up with the following two options: [OPTION 1] We’ll admit, this isn’t ideal This page isn’t responding, but all hope is not lost. You can restore all your crashed tabs, just this one or close it and go on with your day like nothing happened. [√] Tell us about this crash so we keep it from happening again [OPTION 2] There’s good news and there’s bad news The bad news is that this page isn’t responding. The good news is that you can restore all your crashed tabs, just this one or close it altogether. You can even submit a crash report to help prevent more bad news in the future. [√] Tell us about this crash so we can fix it

I dig the whimsical, and if I had to choose, I'd choose Option 2 - but that's just me. Let's see what madhava says. mmaslaney - I really like how the crash report form looks in the tab. Great stuff! I think the layout and the workflow works for me.

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #36) > I dig the whimsical, and if I had to choose, I'd choose Option 2 - but > that's just me. Let's see what madhava says. Thanks! That would be my pick as well. Once we get this to the point where only the one tab is affected by the crash, we could tweak the language so that the "good news" is that you only have to restore one tab and everything else is still working as it should.

(In reply to Matej Novak [:matej] from comment #35) I don't like either. 1. Both are too long. If a tab crashes, the user will most likely want to just click the Reload button and continue their work. Nobody wants to read essays with little informational value. 2. TL;DR "It's too friendly". Both messages sound like a buddy talking to a buddy, like "Hey, your tab crashed and you lost your work or train of thought. Yeah, it's all gone, but no biggie, right?" Stop right there. A browser (and by extension, any other program) is not your buddy, not your friend, and not something that is permitted to talk to you like you're its equal. It's a professional tool that helps you get your work done, whether it's scientific research, editing spreadsheets online, videocalling, or watching porn. If something goes wrong, it's not the user's bad, and the browser should tell the user in a brief and comprehensible, yet not scary way what happened, and offer quick actions. The current text (meaning the text in mmaslaney's mockups) is sufficient for now, but not entirely accurate. "We tried to display" suggests that the tab crashed during its initial loading, and "it's not responding" just isn't the same as crashing (when you try to display a huge image in Firefox, for an amount of time it won't respond, but also won't crash - it just takes its time). The "Well, this is embarrassing" header has become almost Firefox's trademark for trouble, so I would keep it (even though it's personificating Firefox, A COMPUTER PROGRAM, by making it look like it's a living being with a feeling of shame). My suggestion is: Well, this is embarrassing Something went wrong with the contents of this tab, which lead to a crash. You can try: [Close Tab] [Reload This Tab] [Restore All Crashed Tabs] (In reply to mmaslaney from comment #33) A little nitpick: The buttons' labels should be All Caps, like the rest of Firefox's UI. Also, changing "Reload" to "Restore" might still be accurate until we create a single process for all tabs, but once each tab has its own process, it's unlikely (though not impossible) that more tabs would crash at once, so "Reload" will be better then. And also "Restore" suggests restoring the tab from somewhere, presumably from cache, which could lead to repeated crashing, so the tab would have to be hard-refreshed (similarly to hitting Ctrl+F5).

Language aside, I think from an engineering perspective (especially for the crash report form), this spec seems to give us everything we need. Thanks mmaslaney! I think we just need final decisions on strings, graphics and a sign-off from madhava?

I vote for Option 2! One thing that reads a little odd, to my ear, is the phrasing "You can even submit a crash report to help prevent more bad news in the future." Which seems a bit of a hard sell. Submitting a crash report is not the best of the good news - we're asking people to help, rather than that being a reward. Perhaps: "Can we ask you to submit a crash report too, to help prevent more bad news?" Also - if Oxford commas are acceptable at Mozilla (I can't keep track), "The good news is that you can restore all your crashed tabs, just this one or close it altogether" would be a little clearer with a comma after "just this one."

Also - one note about the page layout - let's try indenting the crash reporting UI so that it reads as visually subordinate to the checkbox that shows/hides it. Otherwise, at a glance, it's not clear what belongs to what.

Thanks, Madhava. Much to the dismay of many, we don't use Oxford Commas. I wonder, however, if there's a way to simplify the whole message to address some of the concerns in comment 38 about length and to reword the sentence you mentioned to make it clearer. Here are three alternate versions of Option 2: [VERSION 1] There’s good news and there’s bad news The bad news is that this page isn’t responding. The good news is that you can close just this tab, restore it or restore all your crashed tabs. [√] Submit a crash report to help prevent more bad news [VERSION 2] The bad news is that this tab crashed The good news is that you can close just this tab, restore it or restore all your crashed tabs. [√] Submit a crash report to help prevent more bad news [VERSION 3] Bad news first: This tab crashed Now for the good news: You can close just this tab, restore it or restore all your crashed tabs. [√] Submit a crash report to help prevent more bad news I also wonder if there should be an option to close all affected tabs. It seems like if the user is going to close this one rather than restore it, they may want to do the same to all the crashed tabs.

Historical note: we started out with whimsy in the crash reporter dialog (bug 358082, see attachment 266108 [details] for what the first version of the UI looked like) but changed to the current apologetic tone due to user complaints (bug 385236, bug 404855).

Oh - I like the new Version 3 headline the best, by far. Maybe "This tab has crashed" ? Overall, I also like version 3 the best.

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #43) > Historical note: we started out with whimsy in the crash reporter dialog > (bug 358082, see attachment 266108 [details] for what the first version of > the UI looked like) but changed to the current apologetic tone due to user > complaints (bug 385236, bug 404855). Thanks for the reminder, Ted. I think this older case, like the Chrome "Aw Snap" message is the sort of random "being more human, but a human who's a jerk" tone that we're avoiding here. Dark whimsy?

I dunno, after living in this space for so long I think it's a place where whimsy is best avoided. I love whimsy, but having your browser crash (or a tab crash in this case) is a super-frustrating time, so the tone is extremely likely to be read with unintended meaning. It's especially bad because it's entirely possible to have a situation where you crash multiple times in rapid succession, so you get to see the same message repeatedly, which *really* grates on you.

(In reply to Madhava Enros [:madhava] from comment #44) > Oh - I like the new Version 3 headline the best, by far. Maybe "This tab has > crashed" ? > > Overall, I also like version 3 the best. Great! Here it is with the above revision: Bad news first: This tab has crashed Now for the good news: You can close just this tab, restore it or restore all your crashed tabs. [√] Submit a crash report to help prevent more bad news

I don't know if you're looking for more input, but here's my take on it (I don't really like the good news / bad news thing): Unfortunately, this tab has crashed. You may close it, restore just this tab or restore all tabs that crashed. [√] Submit a crash report to help prevent more issues like this

Thanks for the updated copy, Matej. Please find the updated mock here: http://people.mozilla.org/~mmaslaney/e10s/Firefox-e10s-v5.png

Looks great! I already asked this in comment 42, but in case it got lost in the shuffle, do we need a button for "Close All Crashed Tabs"? Also, let's standardize the button language. Either "Close Tab" and "Restore Tab" or "Close This Tab" and "Restore This Tab." Thanks.

Updated mock: http://people.mozilla.org/~mmaslaney/e10s/Firefox-e10s-v6.png I beleive we should omit the "Close All Crashed Tabs" button, as it's more of a power-user feature. Most users are far more likely to "Restore All Crash Tabs" than "Close All Crashed Tabs".

Assets