Open Bug 765299 Opened 12 years ago Updated 2 years ago

Overhaul crash reporting UX

Categories

(Toolkit :: Crash Reporting, defect)

defect

Tracking

()

People

(Reporter: kairo, Unassigned)

Details

We should have the UX team think about how we can improve the overall crash reporting workflow and UI.


This came out of the discussion of the Crash Reporter dialog not having the best UI to actually drive people to do meaningful comments and also the point in time of when they are asked to comment and give us data being probably the worst possible one due to being the highest frustration point in their experience. From there we realized it might make sense to actually think about designing the ideal UX that crash reporting could have and iterate from there to an implementation.
The existing GUI was designed in bug 358082 and bug 404855.
We also looked at some tweaking in bug 550303.

One of the hurdles here is that this is all native code, which makes it a bit of a pain to change around.

And not to scope-creep this bug, but ISTR there being a bug (or was it just discussion?) of moving the primary method of crash reporting into Firefox. (eg crash reporter would just record the dump, and next start the browser would prompt for submission). We'd still need to retain something for the case of early-startup crashes, though. But we could at least optimize for the case of crashes happening randomly after startup.
(In reply to Justin Dolske [:Dolske] from comment #2)
> And not to scope-creep this bug, but ISTR there being a bug (or was it just
> discussion?) of moving the primary method of crash reporting into Firefox.
> (eg crash reporter would just record the dump, and next start the browser
> would prompt for submission).

I've not heard of such a thing with the exception of B2G, yet. Also, as you say, startup crashes are a concern with that (not for B2G, as the phone needs to be serviced anyhow if it continues to crash on startup). For now, I think all we can reasonably do is to think about the UX with the native-UI crash reporter in place - but as I said in comment #1, I'd love to first hear what our UX team thinks would be the ideal process (that is, assuming we crash at all) and UI and work from there to an implementation.
I would love to move the common-case crash reporting UI into the product. I think that we're probably pretty close to being able to do that now that we have startup crash detection, and we could probably even use recent crash reports to improve that startup crash detection.
That actually raises an interesting point: if we were to switch to using in-product crash report submission for non-startup crashes, then we could rework the existing crash reporter UI to be focused around just startup crashes, which would be neat.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.