Closed Bug 765299 Opened 13 years ago Closed 5 months ago

Overhaul crash reporting UX

Categories

(Toolkit :: Crash Reporting, defect)

Product:
Toolkit
Component:
Crash Reporting
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: kairo, Unassigned)

References

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
Duplicate of this bug: 550303

I'm tempted to close this bug due to age and general ambiguity. I'd prefer more specific bugs relating to UX. Though we could keep this open as a task to have the UX team look at the entire crash reporting experience (both from content and main process crashes). In that case, we should loop them in on this to get things going.

:gsvelto WDYT?

Flags: needinfo?(gsvelto)

Yes, let's close this and open new bugs on a case-by-case basis. We wouldn't be able to ask the UX team for a complete investigation and overhaul without some good motivations for it.

Flags: needinfo?(gsvelto)

Closing for the reasons listed above.

Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.