When the content process of a tab crashes in a multi-process browser, we'll need some UI to present to the user what has happened. This should be simpler than the OOP plugin UI (bug 525849), since we have the area of the entire tab to work with. We should probably present some text similar to the existing crash reporter client--"We're Sorry Firefox had a problem and crashed...". We could display it similarly to the network error pages, although we should make it distinct enough to make it clear that this is not a network error, but an application error. Perhaps we could display the content in a rectangle centered over a grayscale image of the last contents of the tab? In any case, we should provide a "Reload this tab" button. The user can use the existing tab close button to close the tab if they choose. We'll probably want to have a checkbox like the existing crash reporter for "[x] Tell Mozilla about this crash so they can fix it".

I also suggest doing something to the crashed tab itself, for example, if the user is located in another tab. Since I am no good with mockups, I basically suggest something like the red tab at: https://wiki.mozilla.org/images/f/fa/Fx-3.7-Mockup-Mac-i03-Tabs-Up-Integrated.png ...and also replacing the favicon.

Alex: Is this something you want to own? It'll be in 3.7 early next year, so we need to jump on it pretty quick.

OOP Tabs won't ship in 3.7 (AFAIK), but OOP Plugins will (bug 519541 and bug 525849).

Bah. Right. I was thinking of the wrong bug. But this needs UI for Firefox 4. :)

>Alex: Is this something you want to own? Sure, I can own the UI for the set of crashing bugs

Filed the meta bug 535078 for grouping the UI design work related to crashed plugins and tabs.

Continuing on my previous idea, I figured that if we, with the new theme will have the progress lines, we could make use of that for this purpose. If a tab, or a plugin inside that tab crashes, could we have a line that is red? Like https://bug544818.bugzilla.mozilla.org/attachment.cgi?id=425750 but red (and full) instead.

Interesting idea, what's the advantage of drawing the user's attention to the crash though? It seems like they don't have to immediately take any action, and we have to be careful not to distract them from what they are currently doing unless we have a really important reason.

The plugin might be doing something important to the user, where, if the crash is not discovered quickly enough, a lot of time is lost. A quite poor example, I know. The best situation I can come up with that I would find myself in, is a game which I often run in the background to collect resources, while I surf on other pages. I'd like to know if that crashed, so I won't miss out on these "resources". Well, I hope you get the idea. In my opinion, the "crash-line" would not glow, which would, in that case, reduce the "distraction-level" further.

mfinkle, why doesn't this block? We aren't going to get any content-process crash reports unless we have a UI for it. We are not allowed to submit crash reports automatically.

(In reply to comment #10) > mfinkle, why doesn't this block? We aren't going to get any content-process > crash reports unless we have a UI for it. We are not allowed to submit crash > reports automatically. Yeah, my mistake. Thanks

Madhava proposed this UI: http://grab.by/7m4m I still think we need "Close" and "Reload" actions on the UI.

Per the discussion from the original Firefox plugin-crash UI, we really want "submit the crash report" to be more available. Could we have the main button be "submit crash report"? And then when that is clicked, change it to a refresh button? The user always has the option of reloading from the urlbar normally. What would a "Close" button actually do?

The "Close" button closes the tab that caused the crash. The current content crash UI allows the user to "close" or attempt to "reload" the tab that was active when the crash occurred.

How could you possibly know which tab "caused" the crash? I had sorta assumed that close would close Fennec, not the current tab.

(In reply to comment #15) > How could you possibly know which tab "caused" the crash? I had sorta assumed > that close would close Fennec, not the current tab. We don't know for certain, but for all other tabs the user has the option of closing the tab using the normal Fennec UI. However, for the active tab, you don't have that luxury. So we ask you what you want to do. See bug 594847 and bug 603098

Benjamin - my question for you is how to implement the "Submit crash report" feature? What API do we have available?

We have a jsm that gets used for submitting from about:crashes and for submitting plugin crashes: http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/CrashSubmit.jsm

This patch adds the strings needed for the feature. The functionality does not work, but the string will be present for string freeze.

Comment on attachment 490196 [details] [diff] [review] patch (strings) So this adds a checkbox to the UI, but the checkbox does nothing (for now). Would it be better to just add the string to the .properties file without changing the UI, or is the UI change needed for l10n testing? Either way, r=mbrubeck.

(In reply to comment #20) > Comment on attachment 490196 [details] [diff] [review] > Would it be better to just add the string to the .properties file without > changing the UI, or is the UI change needed for l10n testing? Yes, I want l10n to see the strings whenever possible.

pushed strings: http://hg.mozilla.org/mobile-browser/rev/8845bcdad962

Note for triage: This bug depends on bug 581335

Additional patches in bug 581335. UI is done for now.