1758586 - Allow crash signatures to be tagged as "need info from users", so that users who crash with that signature can be invited to provide more info

Status: NEW

(Toolkit :: Crash Reporting, enhancement)

Description

[Daniel Holbert [:dholbert]]

For crashes where we're actively investigating but somewhat stumped, it would be really handy if we could "tag" the crash signature in such a way that extends the crash-reporter dialog to invite the user to engage with us.

e.g. for "tagged" crash signatures, maybe we'd show an additional blurb in the crash-reporter dialog, which would say something along the lines of:

"Firefox developers have investigated earlier automated reports of this crash, and they need some additional information or assistance from affected users in order to better-understand the issue. If you're willing to help out, please post a comment at [link to bug], and you might just help us fix the crash!"

(This would be particularly handy for crashes that seem to involve the same small set of users are hitting the crash over and over, due to some particular configuration or due to their particular hardware.)

Comment 1

[Daniel Holbert [:dholbert]]

Note: technically, users can already discover and engage on a bug report for their recent crash, if they know what to do -- they can visit about:crashes and then click a crash report, and then click the Bugzilla tab, and see that there's already a bug filed for their crash signature; and then at that point they could add a comment if they want, to let us know that they're affected & can provide more info.

But users typically aren't (and shouldn't be) aware that about:crashes even exists, so usually this won't happen.

So: the idea here would be that for crash-bugs where we have a particular interest in inviting users to provide additional info to help fill in gaps in our knowledge, we might add some extra outreach invitation in the crash reporter dialog itself, if that's possible. (I'm imagining this would be done locally via a list of "tagged" signatures that we ship encoded in an about:config pref, for example, or as some other local & periodically-updated piece of data.)

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

There are two sides to this bug: the crash reporter side and the crash ingestion side. I figure I'll weigh in on the crash ingestion side.

In the 6 years I've been working on crash ingestion, I've heard variations on this idea multiple times. I don't know if there are bugs with previous discussions. I do know that so far, it's always been a hard enough problem that the answer has always been a hard no. However, I think crash ingestion has come a long way since the last time it came up and we've got a new stackwalker which gives us a lot more options, so maybe it's not a hard no anymore?

On the crash ingestion side, the problem is that the collector of the crash ingestion pipeline doesn't have the information it needs to know to ask for more information. The collector doesn't parse minidumps for incoming crash reports--that happens later in the processor as well as normalization and calculation of other values that are used in signature generation. Because of that, the collector can't know the crash signature for a crash report.

Maybe we could merge the collector and processor? This would be a huge re-architecture for the crash ingestion pipeline. It's not something I can think about right now. Maybe in a couple of years.

But maybe we don't need a crash signature and we could use any kind of fingerprint? At some point in crash reporting for Firefox, the minidump_analyzer generates the stack of the crashing thread which is sent with the crash ping data. If that stack was sent as a crash annotation with the crash report, then maybe the collector could use that to determine whether we want more information for this crash report (or even whether this crash report should be throttled).

You could look at the stacks in the crash ping data to see if that stack data is coarse/fine enough for a usable fingerprint.

Gabriele or someone else can talk about the complexity of a project like this in regards to the crash reporting client and ui.

Comment 3

[Gabriele Svelto [:gsvelto]]

This is something we had discussed in the helpful crash reporter GSoC (bug 1565026) and I still feel that the best way to implement it is within the crash reporter client (which is pending a Rust rewrite this year) with a little help from Socorro. The flow would go like this:

• We submit the crash and it's processed as usual
• Socorro ingests the crash and responds like it already does... but if there's already a bug for that particular signature sends it back along with the usual response
• The crash reporter client uses the bug information to display some info to the user

As for what we'd show I guess it depends on what we want to do. It could be as simple as something like "we're already working on this issue see bug XYZ". Additionally if the bug had a specific keyword set (needinfo-from-user?) we could prompt the user to go there and help out. Once we can point the crash reporter client to a bug there's no limits to what we can do: from suggesting the user to update its graphics driver to blaming their anti-virus vendor, etc...