1027795 - Breakpad dialog buttons are confusing and possibly all "bad" when Firefox is already running. Change "quit" to close?

Status: NEW

(Toolkit :: Crash Reporting, defect)

Description

[Peter Bengtsson [:peterbe]]

It looks something like this: http://media.askvg.com/articles/images/Mozilla_Crash_Reporter.png

My story is this: I often don't even notice that firefox crashed. Very common is that I have so many windows running that the breakpad dialog is hidden behind other windows and it's very common for me to just start firefox up again after it has crashed without noticing that the breakpad dialog could do that for me. 

(Side note: as a human it's more important to me to get back into the browser ASAP than it is to take the time and address the breakpad dialog so often I priorities starting firefox again rather than dealing with the crash)

So, what happens oftentimes is that I have firefox running AND the Breakpad dialog open too. Sooner or later I notice the breakpad dialog and I want to send in the crash (I'm using Aurora so I want to do a good deed). At that point, none of the buttons make sense. I don't want to "Restart Firefox" and I certainly don't want to "Quit Firefox". I just want to send the crash report and make the breakpad dialog go away.

Comment 1

[(not currently active) Ted Mielczarek]

Right. As originally implemented we wanted the workflow of "get me back to a working browser" to be as simple as possible, hence the "Restart Firefox" button. I agree that under this scenario it doesn't make sense!

The minimal change we could do here would be to make the "Quit Firefox" button just say "Quit". That would be less confusing, I suppose.

A slightly more involved change would be to have the buttons have different text based on the status of the checkbox, so something like:

[X] Tell Mozilla about this crash

    [ Send and Quit ] [ Send and Restart Firefox ]

vs:

[ ] Tell Mozilla about this crash

    [ Quit ] [ Restart Firefox ]

Comment 2

[Peter Bengtsson [:peterbe]]

Again, I'm not a UX expert but I feel like "Close" would be more appropriate. As in, "Close the dialog" which works better in my head than "Quit the dialog".

Comment 3

[Robert Kaiser]

(In reply to Peter Bengtsson [:peterbe] from comment #0)
> So, what happens oftentimes is that I have firefox running AND the Breakpad
> dialog open too.

The UX was not made for you, it was made for 99% of our users that always have only at most one copy of Firefox running.

Comment 4

[Peter Bengtsson [:peterbe]]

(In reply to Robert Kaiser (:[e-mail]) from comment #3)
> (In reply to Peter Bengtsson [:peterbe] from comment #0)
> > So, what happens oftentimes is that I have firefox running AND the Breakpad
> > dialog open too.
> 
> The UX was not made for you, it was made for 99% of our users that always
> have only at most one copy of Firefox running.

I only have 1 copy of Firefox running. In some rare cases I open multiple windows but that's still just 1 copy running.

I know it wasn't made for me but imagine yourself in someone else's shoes who's not very confident around a computer: The browser suddenly disappears. You know you want to go back to Firefox so you click the Firefox icon again to complete the task you were possibly in the midst of. Once you're done, you might close or minimize Firefox and look at what other apps are open and then you notice the Breakpad dialog.

Comment 5

[Robert Kaiser]

(In reply to Peter Bengtsson [:peterbe] from comment #4)
> I know it wasn't made for me but imagine yourself in someone else's shoes
> who's not very confident around a computer: The browser suddenly disappears.

If the Breakpad window is not instantly opening above all other windows when this happens, that is the actual bug, IMHO.

Comment 6

[Peter Bengtsson [:peterbe]]

Please let's not assume that people understand that the Breakpad dialog is "related" to Firefox. Your 99% user will not get that connection immediately. It might be scary looking or they might think it was there all along but only now you see it when Firefox is gone. 

But let's not distract from the issue at hand, which is: you have Firefox (back) up and running and you have a breakpad dialog whose buttons no longer "make sense".

Comment 7

[Dave Miller [:justdave]]

I like Ted's idea in comment 1 (although I agree that "close" is probably better than "quit").

I've actually done this many times myself - had Firefox crash, and start it myself before noticing there was a Breakpad dialog.  "technically" Firefox is already gone at the point when Breakpad comes up.  So saying to "Restart Firefox" is technically invalid because it's not running to restart it at that point.  Unless you've manually run it yourself, and then the dialog is scary because you think it'll make the one you just ran go away again.  Probably the only real user-friendly way to do this is to watch the process list and change the button text if it detects Firefox is running again.  That's probably a tall order to accomplish though.  Most people when thinking about computers and you say to "Restart" something, that means to take something that's already running and make it start over.

Maybe:

[X] Tell Mozilla about this crash

    [ Send and Quit ] [ Send and Start Firefox Again ]

and:

[ ] Tell Mozilla about this crash

    [ Quit ] [ Start Firefox Again ]


I know "Restart" is semantically a less wordy way of just saying "Start Firefox Again" but as pointed out, "Restart" has different connotation when dealing with computer software.

Quite amusingly, Firefox crashed on me *while* I was typing this comment.  Go figure.

Comment 8

[Robert Kaiser]

Also, note that small changes in the UX of the crash reporter can vastly change our rate of crash submissions and therefore the data we have in crash analysis. So we need to be careful with what we do here.

Comment 9

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Let's get some UX design bandwidth on this - IMO, the whole dialog is awful and needs rethinking.

Comment 10

[Wayne Mery (:wsmwk)]

(In reply to Robert Kaiser (:[e-mail]) from comment #8)
> Also, note that small changes in the UX of the crash reporter can vastly
> change our rate of crash submissions and therefore the data we have in crash
> analysis. So we need to be careful with what we do here.

Can FHR or something else help us understand how the crash submission rate compares to the crash rate?

Comment 11

[Robert Kaiser]

(In reply to Wayne Mery (:wsmwk) from comment #10)
> Can FHR or something else help us understand how the crash submission rate
> compares to the crash rate?

Yes, this is being worked on but not done yet, see bug 994707 and bug 994708.

Comment 12

[Wayne Mery (:wsmwk)]

along the lines of comment 0, see bug 714133 comment 12


(In reply to Blair McBride [:Unfocused] from comment #9)
> Let's get some UX design bandwidth on this - IMO, the whole dialog is awful
> and needs rethinking.

This bug is a probably duplicate (ref: Bug 714133 and bug 550303, which was initially merely about cosmetics irrc, and side issues such as bug 444356 and bug 336872 and bug 511462) but perhaps it can be a nice fresh start.

You might consider more than "cleaning", with an eye toward helping address some long overdue items (some mentioned in other bug reports)
1. help users with startup crashes 
2. help users with frequent crashes 
3. account for odd situations (example firefox was already restarted = comment 0)
4. get better user crash comments - we should be able find wording that will encourage users to provide more useful crash comments (which might also help reduce unuseful bad language) - this may not be important to Firefox, but it is to Thunderbird
5. some users still cite the useless "details" section when they are asked for a crash ID.
6. users (Windows users anyway) are not accustomed to application crashes and the current dialog is not particularly comforting to users experiencing their first crash. 
7. there has been concern that the window styling and the wording (eg window title "Mozilla crash reporter") doesn't tie in well to the product. Might it be different enough that some users are inclined to ignore it?

Can we actually "do more with less" via a collapsible section, suggested in bug 714133 comment 5?  
Or would an intro panel for first time crashers be overkill?

Last note because there has been concern in the past that a dialog that delays the user in any way risks losing significant numbers of crash reports.  Perhaps true. But I think we can be far less concerned about this today than 4-5 years ago, in part because we look at crash reports in the aggregate. Plus, we are creative and I am optimistic we can achieve multiple goals so that we can better help users including those outside the average crash situation (some dire).

Comment 13

[(not currently active) Ted Mielczarek]

(In reply to Blair McBride [:Unfocused] from comment #9)
> Let's get some UX design bandwidth on this - IMO, the whole dialog is awful
> and needs rethinking.

There are lots of bugs on "redesign the whole dialog" as Wayne points out. I'm not opposed to that, but that's a large project and I don't think we should block small improvements on that. This bug as filed points out one scenario where the button text is confusing and we could fix it without boiling the oceans.