Enhance Crash Recovery to better help the user

NEW
Unassigned

Status

()

--
enhancement
10 years ago
a year ago

People

(Reporter: bc, Unassigned)

Tracking

(Depends on: 4 bugs, {meta})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: [crashkill][crashkill-metrics])

(Reporter)

Description

10 years ago
When our users crash they are pretty much in the dark about what caused the problem. They don't know about about:crashes or crash-stats.mozilla.com and probably for the most part don't care. But they do care that they are crashing. Some of them seem to be caught in an endless cycle of crashes without any idea of why.

I think we can use the restore session page after a crash to better help our users by:

1. providing some indication of what caused the problem. If we can get to the data that is submitted to Socorro and analyze the top frame of the stack, we might be able to tell them that a specific plugin or addon is responsible for the crash and which page most likely caused the crash.

2. providing an easy way to disable the plugin or addon from the session restore page.

Perhaps this is something that could be included in a UI sprint for 3.5.
Dave Garret's Crash reporter addon does a good job at part 1, https://addons.mozilla.org/en-US/firefox/addon/11217. Maybe something like that.
(Reporter)

Comment 2

10 years ago
I'm checking it out right now. Thanks for the pointer! One thing though is we probably want to process the local crash data so as to not hit the Socorro servers too hard.

Comment 3

10 years ago
#2 is done via a button in the "Last Crash Information" dialog that comes up after a crash if it's an add-on's doing.

This is duplicated in part with bug 336872.

Updated

9 years ago
Depends on: 523350

Updated

9 years ago
Depends on: 336872

Updated

9 years ago
Depends on: 523427
Whiteboard: [crashkill][crashkill-metrics]

Updated

9 years ago
blocking1.9.2: --- → ?

Updated

9 years ago
blocking1.9.2: ? → ---
blocking2.0: --- → ?
This would be a big improvement. However, not having it doesn't prevent or regress major functionality in the browser, so not going to hold the release for it.

If someone steps up and makes a patch that's low-footprint and well-tested, we'd take it.
blocking2.0: ? → -

Comment 5

9 years ago
should this get a "minus" for 2.0 instead of setting back to a "null state" nomination so it stays in a pool for the next release?

Comment 6

9 years ago
ah, I guess it did...  more coffee...

Updated

7 years ago
Depends on: 595239

Updated

6 years ago
Depends on: 765296, 869616, 411425
Keywords: meta

Comment 7

5 years ago
dev-platform thread "Rethinking the crash experience":
https://groups.google.com/forum/#!topic/mozilla.dev.platform/JE-E17Sp9rE

Intern project "Improving Support After Firefox Crashes":
https://docs.google.com/document/d/1dZkkjDh87k4UH4Gcv_gA_pkTo8yIR88l_Dxs2fXKJRs
Depends on: 1024677

Updated

4 years ago
Depends on: 1042394
You need to log in before you can comment on or make changes to this bug.