Open Bug 336872 Opened 18 years ago Updated 2 years ago

Give Breakpad users immediate feedback based on signature or stack trace

Categories

(Toolkit :: Crash Reporting, enhancement)

enhancement

Tracking

()

People

(Reporter: jruderman, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: sec-want, Whiteboard: [sg:want][crashkill][crashkill-metrics])

It would be great if we could give Talkback users a message based on the stack trace as soon as they submit it.  These messages could be used to:

* Suggest workarounds.
* Shift blame to plugin authors.
* Inform users of our progress (working on a fix, stuck needing steps to reproduce, etc).
* Request detailed information where it's really needed (security holes, frequent crashes that developers can't reproduce).

Examples:

* 0x######## -> "The crash you reported is probably a security hole in Firefox.  We'd *really* appreciate information about how to reproduce it."

* "This is a trunk-only regression that started on May 3.  David Baron is working on it furiously."

* "This is a trunk-only regression that started on May 2.  Upgrade to a build from May 5, 2006 or later to fix it."

* "This crash may be caused by an old version of the Adblock extension.  Update to version X or higher to fix it."

* "This is fixed on the trunk and will be fixed in Firefox 3.  If you're feeling advenurous, or if this particular crash is really annoying you, try a trunk nightly."

* "If you can provide steps to reproduce this crash reliably, please please please add them to bug 333333 in bugzilla.mozilla.org.  We're stuck."

* "Rumor has it that turning off smooth scrolling (in advanced options) makes this crash go away."

* NPSWF32.dll -> "This appears to be a crash involving the Macromedia Flash plugin.  Most likely, it's a bug in Flash rather than a bug in Firefox.  Try disabling or updating the plugin"

* Generic message: "Crashes in nsXULDocument::AttributeChanged account for 1.6% of Firefox 1.5.0.3 crashes (#7 on the topcrash list)"

I'm guessing this would require big changes to the Talkback client and server. It might also mean changing Talkback so it submits the crash before letting you enter an email address and comments.

We can already do this with email, but not easily, and few users give their email addresses, and we'd reach them long after they've forgotten what they were doing when their browser crashed.

I think Microsoft tries to do something like this, but they don't do it well:
http://www.squarefree.com/2005/12/18/microsoft-crash-reporting-and-firefox/.
Whiteboard: [sg:want]
talkback has this feature and we have used it in the past on selected incoming stack traces to do things like suggest upgrades needed for plugins that are causing crashes...

only requirement is that the user provide an e-mail when submitting the blackbox.  We take the filling out of the e-mail address field as action that it is ok to contact the user.  If we did some kind of other communication channel like I think comment zero suggests we would have to also let the user opt in to being contacted. 

jay knows how to set up the messages.

On the content of the messages I think it breaks down into two categories.  Bugs that we know what is going on, and those that we don't.  I think the auto responder is good for the bugs that we know what is going on, but on the ones that we don't I think we might only send up meaningless alarms.  We should just focus on analyzing and harvesting the data that we already have instead of scaring or confusing the general user population.

I suggest this bug be marked WFM or used as a metabug to track instances where we could use autoresponder message via e-mail right now...
> talkback has this feature... only requirement is that the user provide an 
> e-mail when submitting the blackbox

I already addressed that when I opened this bug:

"We can already do this with email, but not easily, and few users give their
email addresses, and we'd reach them long after they've forgotten what they
were doing when their browser crashed."

> I think the auto responder is good for the bugs that we know what is going 
> on, but on the ones that we don't I think we might only send up meaningless 
> alarms.  We should just focus on analyzing and harvesting the data that we 
> already have instead of scaring or confusing the general user population.

I think that sometimes we don't have enough information to fix the crashes, or to know which ones can be reproduced at all.

The point about scaring/confusing users makes sense (especially for the "The crash you reported is probably a security hole in Firefox" message), but maybe we can find a way to avoid confusing too many users while still getting the information they need.  Remember, this would only show up for the few users who are already experiencing crashes.
I like this idea a lot, but we should use less technical jargon in the messages and provide a link to more details for people who want to dig into it. Some suggested reworkings of your examples:

* NPSWF32.dll -> 

   .----.
   | Rx | This problem seems to be related to Macromedia Flash. Please try 
   |    | re-installing or updating your plugin. You can get the latest 
   '----' version _here_.

          _Find out more_

                                                                   [ OK ]
* Generic message ->

   .----.
   | Rx | We don't know what caused this crash yet, but we do know that 
   |    | it accounts for 1.6% of the crashes we see in Firefox 1.5.0.3 
   '----' Your data will help us diagnose the problem!

          _Find out more_

                                                                   [ OK ]
I also think this is a great idea...and that is why I setup the feedback scripts back at Netscape to send quick workarounds for major topcrashers.  We used it quit a bit during the Netscape 6.x days, and it seemed to work well.  

However, with our growing userbase and the hackiness of my scripts, I would rather design and implement a more stable system with a better user interface to make things like managing topcrashers, generating the feedback, and tracking contacted users a lot easier.

beltzner:  I agree that we need to be careful with our wording to users, since a lot of the stuff related to crashes might be too technical for the avg. user.  We used to have Netscape marketing provide us with with the feedback text and I then included that in the email messages sent out.  Hopefully we can get the MoCo marketing/pm team to do the same for major crashes we want to address.
Ted, is Airbag likely to support this kind of thing?
I don't see why not.  Assuming we can process the reports in realtime, you should be able to provide immediate feedback to the user.  If not, then it'd be a little trickier, since you'd need an email address or you'd have to give the user a link to check up on later, which is what Microsoft does and isn't very useful.
iirc doesn't breakpad ask for an email address, and also say something to effect that "we will email you went the problem is resolved?"
Depends on: 408721
Product: Core → Core Graveyard
Assignee: jay → nobody
Component: Talkback Client → Breakpad Integration
Product: Core Graveyard → Toolkit
QA Contact: chofmann → breakpad.integration
Summary: Give Talkback users immediate feedback based on signature or stack trace → Give Breakpad users immediate feedback based on signature or stack trace
The "Crash Report Helper" extension does something along these lines. https://addons.mozilla.org/en-US/firefox/addon/11217
See also bug 511462 and bug 506338.
Blocks: 506338
Whiteboard: [sg:want] → [sg:want][crashkill][crashkill-metrics]
bsmedberg: this is functionally your "process all crashes, email users" bug, right?
Flags: needinfo?(benjamin)
It is, mostly. The details are a little different.
Flags: needinfo?(benjamin)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.