550303 - Update crash-reporter UI and tweak visual style

Status: RESOLVED DUPLICATE of bug 765299

(Toolkit :: Crash Reporting, defect)

Description

[Justin Dolske [:Dolske]]

The current standalone crash-reporter UI could use some visual refinement. Specifically, the various elements in the dialog are a bit jumbled (eg, 5 separate horizontal alignments in the Windows flavor).

Some string changes (eg bug 531881) might be worth doing as part of this, though I'd like mostly keep this focused on just making what's already there look better via position/size changes.

Comment 1

[Justin Dolske [:Dolske]]

Attachment: Current trunk screenshots

Comment 2

[Justin Dolske [:Dolske]]

Background: last round of UI changes was in bug 404855,

Comment 3

[(not currently active) Ted Mielczarek]

That bug bears reading if you haven't already, there's a lot of info there including various mockups we worked through. That being said, there's definitely room for improvement, having shipped basically the same UI in three versions of Firefox. bug 531881 and bug 448894 are probably the lowest-hanging fruit.

Comment 4

[Justin Dolske [:Dolske]]

(Oops, I must have triggered the Windows screenshot on a blank page, because the "Include address of the page I was on" checkbox is missing. Retried and it does display when a page is loaded.)

Comment 5

[Justin Dolske [:Dolske]]

Attachment: Mockup v.1

Here's a mockup with my basic thinking...

* Align things full-left or full-right.
* Combine first two text blobs. It's longer, but 1 less visual element.
* Remove email checkbox.
* Add a checkbox to make submission (or not) automatic w/o prompting.
* Change buttons to control report submission. Seems more natural, as well as making it more obvious to users what's going to happen.

Other notes:

* Maybe add some text below email field to the effect of "Your email address will only be used to allow an developer to ask you questions if needed."? Not sure if enough people will just enter it anyway.

* Reporter will always attempt to relaunch Firefox. Bug 421552 added "Quit" to prevent infinite loops, I think it would be better (as well as required for the automatic-submission case) for us to detect this instead of making the user deal with it. EG, have the browser flip some bit after delayed-startup + 60sec that it's ok for the crash-reporter to restart. [I guess the buttons would become just "Submit" and "Don't submit" then.]

Comment 6

[(not currently active) Ted Mielczarek]

We went around and around on the buttons vs. checkbox thing, and I still think that having separate quit and restart buttons are better. I agree that we should also be doing some smarter things with detecting startup crashes, but 

Combining the two sentences into one blob trades some vertical space for readability, I think. It turns it into more of a "block of text".

The alignment stuff looks good, and ditching the "email me" checkbox is also probably a good idea. If we're going to remove that, though, we should provide some kind of text to indicate what it's for (and fix bug 531881 in the process).

Also, I really do like the language we currently include in the submit checkbox, "Tell Mozilla about this crash so they can fix it". I think it gives users a very clear reason why they should opt to send a crsah report.

Comment 7

[(not currently active) Ted Mielczarek]

(In reply to comment #6)
> We went around and around on the buttons vs. checkbox thing, and I still think
> that having separate quit and restart buttons are better. I agree that we
> should also be doing some smarter things with detecting startup crashes, but 

apparently I didn't finish this thought. :) Even if we have some smart detection, it's not going to account for all cases, and I always want the user to have an easy way out, and not frustrate them by making Firefox restart if they are fed up and just want to quit.

Comment 8

[Dave Garrett]

Please remove/replace the details button while you're here. (bug 448894) There are arguments to have "something" here that is useful, but this button isn't.

Voice of paranoia: I don't trust the application to be able to handle infinite crash loops without a quit button. If we're at the crash dialog already, to some degree we're already not handling things as was intended. Better automatic handling would be great, but I don't think it should be relied on entirely.

Below the checkbox line for including the page address, it would be nice if it actually listed the URL so users see what they're submitting.

Comment 9

[Justin Dolske [:Dolske]]

I think the automatic restart can be quite reliable. To expand on what I wrote in comment 5... 

We already have one layer of protection in the browser (which I believe is newer than the last crash reporter redesign), in that session restore will display an error page if it detects that the browser didn't finish restoring last time it was started. So, if page content is causing a crash, session restore will catch it on the 2nd restart.

We should also add an additional layer of protection, by having the crash reporter *not* restart the browser unless the browser sets a flag allowing it to (probably as part of the above session restore sanity check, plus an additional time delay). So if, say, an extension was causing a startup crash, the browser wouldn't run long enough to enable restarting in the crash reporter.

Comment 10

[u294409]

What if not everybody wants to restart the browser? He may resign ;-) .

Comment 11

[galois641]

> Below the checkbox line for including the page address, it would be nice if it
> actually listed the URL so users see what they're submitting.

I strongly support Dave's suggestion! I came to bugzilla to file precisely suggest this feature. It'd best to make the display the URL(s) explicitly since the user may unwittingly publicly link his e-mail and visited pages, which may contain things like login tokens. (Btw, does this also hold for private browsing mode?) Moreover, it would be great to have a button that would show *all* the information that would be submitted to Mozilla.

Comment 12

[(not currently active) Ted Mielczarek]

The "Details" button currently shows all the information that we can display in a useful form to the user. It leaves out the contents of the minidump, which is a binary file (it's what we generate the stack trace from). I don't think there's any way to usefully present that data to the user.

Comment 13

[Justin Dolske [:Dolske]]

(clearing assignment of bugs I'm no long planning to work on)

Comment 14

[Robert Kaiser]

(In reply to Justin Dolske [:Dolske] from comment #5)
> * Add a checkbox to make submission (or not) automatic w/o prompting.

That does away with getting new comments from people. In many cases, those comments are vital for us to diagnose/reproduce the crashes. How would we solve that issue?

> * Change buttons to control report submission. Seems more natural, as well
> as making it more obvious to users what's going to happen.

Makes it much harder to identify what the buttons do (way longer text to read on them), gives us no chance to break out of a startup-crash loop (no "quit", only "restart"), and makes it way more likely for people to opt out of submission, which we don't want. I'm not so happy about that.

I filed a new report in bug 765299 where I request that the UX team goes rethinking the whole UX of reporting crashes, I'd really like to hear how they think the process and UI should be ideally (well, ideally we don't crash but in case we do) and iterate on design, process and code from there.

Comment 15

[Justin Dolske [:Dolske]]

(In reply to Robert Kaiser (:[e-mail]) from comment #14)
> (In reply to Justin Dolske [:Dolske] from comment #5)
> > * Add a checkbox to make submission (or not) automatic w/o prompting.
> 
> That does away with getting new comments from people. In many cases, those
> comments are vital for us to diagnose/reproduce the crashes. How would we
> solve that issue?

Adding the ability to update/add comments after-the-fact could take care of that. Crash -> autosubmit -> open new tab with some kind of landing page asking if they can provide more info (could even be crash-specific info, if we wanted to get fancy!).

ISTR the ability to edit reports after submission was useful in a few other cases, which I don't recall offhand.

> I filed a new report in bug 765299 where I request that the UX team goes
> rethinking the whole UX of reporting crashes, I'd really like to hear how
> they think the process and UI should be ideally (well, ideally we don't
> crash but in case we do) and iterate on design, process and code from there.

FWIW I'm pretty that limi and I made these mockups together at a workweek. (I won't hold him to 2-year-old mockups, though. ;-)

Comment 16

[Robert Kaiser]

(In reply to Justin Dolske [:Dolske] from comment #15)
> Adding the ability to update/add comments after-the-fact could take care of
> that.

Pretty hard to do technically from all I heard on the stability work week, where we actually discussed this.

> FWIW I'm pretty that limi and I made these mockups together at a workweek.

1) That's interesting (esp. as the design of those buttons sounds not like what I'd expect from limi - he usually has very clear descriptions on them and those sound a lot like "whatever" on both option to my brain), 2) probably not starting from a clean "how would it work ideally" stance, though, which actually would be helpful, I'd think.

Still, there are surely interesting ideas floating around here, and even that can be helpful to come to something better in the end!

Comment 17

[Alex Franchuk [:afranchuk]]

With the new crash reporter client, some of the technical details here are no longer applicable, but the new client has a UI that is very similar. That being said, this bug is very old and the UI has not been changed much in that time. So it might be worthwhile to work with some UX folks to determine whether we want to change the layout. The new code makes this very easy.

Comment 18

[Alex Franchuk [:afranchuk]]

Closing in favor of bug 765299.