(not currently active) Ted Mielczarek Reporter
	Description • 15 years ago

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".

	d
	Comment 1 • 15 years ago

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.

	Samuel Sidler (old account; do not CC)
	Comment 2 • 15 years ago

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.

	(not currently active) Ted Mielczarek Reporter
	Comment 3 • 15 years ago

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

	Samuel Sidler (old account; do not CC)
	Comment 4 • 15 years ago

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

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 5 • 15 years ago

>Alex: Is this something you want to own?

Sure, I can own the UI for the set of crashing bugs

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 6 • 15 years ago

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

	d
	Comment 7 • 14 years ago

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.

	Alex Faaborg [:faaborg] (Firefox UX)
	Comment 8 • 14 years ago

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.

	d
	Comment 9 • 14 years ago

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.

	Benjamin Smedberg
	Comment 10 • 14 years ago

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.

	Mark Finkle (:mfinkle) (use needinfo?) Assignee
	Comment 11 • 14 years ago

(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

	Mark Finkle (:mfinkle) (use needinfo?) Assignee
	Comment 12 • 14 years ago

Madhava proposed this UI:
http://grab.by/7m4m

I still think we need "Close" and "Reload" actions on the UI.

	Benjamin Smedberg
	Comment 13 • 14 years ago

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?

	Mark Finkle (:mfinkle) (use needinfo?) Assignee
	Comment 14 • 14 years ago

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.

	Benjamin Smedberg
	Comment 15 • 14 years ago

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

	Mark Finkle (:mfinkle) (use needinfo?) Assignee
	Comment 16 • 14 years ago

(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

	Mark Finkle (:mfinkle) (use needinfo?) Assignee
	Comment 17 • 14 years ago

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

	(not currently active) Ted Mielczarek Reporter
	Comment 18 • 14 years ago

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

	Mark Finkle (:mfinkle) (use needinfo?) Assignee
	Comment 19 • 14 years ago

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

	Matt Brubeck (:mbrubeck)
	Comment 20 • 14 years ago

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.

	Mark Finkle (:mfinkle) (use needinfo?) Assignee
	Comment 21 • 14 years ago

(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.

	Mark Finkle (:mfinkle) (use needinfo?) Assignee
	Comment 22 • 14 years ago

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

	Mark Finkle (:mfinkle) (use needinfo?) Assignee
	Comment 23 • 14 years ago

Note for triage: This bug depends on bug 581335

	Mark Finkle (:mfinkle) (use needinfo?) Assignee
	Comment 24 • 14 years ago

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