Add an annotation to describe how a crash report was submitted
Categories
(Toolkit :: Crash Reporting, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox101 | --- | fixed |
People
(Reporter: gsvelto, Assigned: gsvelto)
References
Details
Attachments
(1 file)
|
48 bytes,
text/x-phabricator-request
|
willkg
:
data-review+
|
Details | Review |
We currently have only one annotation describing how a crash report was submitted, it's SubmittedFromInfobar and its name suggests that it is present when a crash report was submitted by clicking on the infobar (which typically happens for unsubmitted crashes in the nightly channel). This isn't entirely true however as all crashes that are auto-submitted are also flagged with SubmittedFromInfobar.
To get better visibility into where our crashes are coming from I suggest replacing that annotation with another that has multiple value. Let's call it SubmittedFrom, it could have the following values:
- Auto - the user had opted-in to auto-submission and this was sent that way
- Infobar - the user clicked on the infobar to submit the crash
- AboutCrashes - the user sent the crash from the about:crashes page
- CrashedTab - the user sent the crash from a crashed tab page
- Client - the user sent the crash using the crash reporter client
|
Assignee | |
Comment 1•3 years ago
|
||
CC'ing some people who might be interested. The idea here is to get better visibility into where our crashes are coming from, especially in a post-Fission world and when dealing with processes that have no direct way of submitting crash reports (GPU process, socket process, etc...). If you think that the list above should be expanded just let me know about it.
|
||
Comment 2•3 years ago
|
||
I would love to have this. Huge +1 from me.
|
|
Assignee | |
Comment 3•2 years ago
|
||
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 4•2 years ago
|
||
Comment on attachment 9271302 [details]
Bug 1702509 - Add an annotation describing how a crash report was submitted r=KrisWright
- What questions will you answer with this data?
From where are crashes being submitted? Which are the reporters that work and which are those that don't? Are crashes being correctly sent from all reporters? This should also help detect issues like bug 1693815 comment 15.
- Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements? Some example responses:
We want to evaluate how effective are the various ways of reporting crashes and we want to monitor their effectiveness. This is for the sake of ensuring the browser's stability.
- What alternative methods did you consider to answer these questions? Why were they not sufficient?
We already had the SubmittedFromInfobar crash annotation but it covered only one way the users have to submit crash reports, there's four more that weren't covered. This change removes that annotation as it's superseded by the new SubmittedFrom one.
- Can current instrumentation answer these questions?
No, we can only guess what mechanism was used in most cases.
- List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories found on the Mozilla wiki.
| Measurement Description | Data Collection Category | Tracking Bug # |
|---|---|---|
| SubmittedFrom annotation | Category 2: Interaction data | 1702509 |
- Please provide a link to the documentation for this data collection which describes the ultimate data set in a public, complete, and accurate way.
The annotation description is provided in CrashAnnotations.yaml
- How long will this data be collected? Choose one of the following:
The crash reporting working group wants to permanently monitor this data
- What populations will you measure?
All Firefox users across all release channels in all locales
- If this data collection is default on, what is the opt-out mechanism for users?
As with everything crash reporting this is strictly opt-in, opt-out is the default in this case
- Please provide a general description of how you will analyze this data.
We'll monitor the numbers on crash-stats.mozilla.org to figure out how the various reporters are doing.
- Where do you intend to share the results of your analysis?
Within the crash reporting working group. We have MLs and Matrix channels where we'll discuss this data.
- Is there a third-party tool (i.e. not Glean or Telemetry) that you are proposing to use for this data collection? If so:
No, this will use the normal crash reporting pipeline and won't go into telemetry.
|
|
||
Comment 5•2 years ago
|
||
Comment on attachment 9271302 [details]
Bug 1702509 - Add an annotation describing how a crash report was submitted r=KrisWright
- Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?
Yes--CrashAnnotations.yaml.
- Is there a control mechanism that allows the user to turn the data collection on and off?
Yes. Crash reporting is opt-out by default.
- If the request is for permanent data collection, is there someone who will monitor the data over time?
This isn't necessary for crash report annotations.
- Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
Category 2: interaction.
- Is the data collection request for default-on or default-off?
default-off
- Does the instrumentation include the addition of any new identifiers?
No.
- Is the data collection covered by the existing Firefox privacy notice?
Yes.
- Does there need to be a check-in in the future to determine whether to renew the data?
No.
- Does the data collection use a third-party collection tool?
No.
Pushed by gsvelto@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5382bd66d8f7 Add an annotation describing how a crash report was submitted r=KrisWright
|
||
Comment 7•2 years ago
|
||
Backed out for causing failures on browser_UnsubmittedCrashHandler.js . CLOSED TREE
Backout link: https://hg.mozilla.org/integration/autoland/rev/89e79862c05fb056400ae79a3d5940ac3a9372e5
Link to failure log :
https://treeherder.mozilla.org/logviewer?job_id=375113601&repo=autoland&lineNumber=5650
https://treeherder.mozilla.org/logviewer?job_id=375121949&repo=autoland&lineNumber=47311
|
|
Assignee | |
Comment 8•2 years ago
|
||
I've identified the problem: I let an unrelated change slip in the patch and it was the cause of the intermittent. I'll reland the patch with the changes removed.
Pushed by gsvelto@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ac56b5d2c58e Add an annotation describing how a crash report was submitted r=KrisWright
|
||
Comment 10•2 years ago
|
||
| bugherder | ||
Description
•