Telemetry measures for browser error collection

RESOLVED FIXED in Firefox 61

Status

()

enhancement
P1
normal
RESOLVED FIXED
Last year
7 months ago

People

(Reporter: osmose, Assigned: osmose)

Tracking

Trunk
Firefox 61
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox60 wontfix, firefox61 fixed)

Details

Attachments

(2 attachments)

In order to monitor browser error collection and measure its usefulness, I'd like to add six new scalars to the main ping:

browser.errors.collected_count
    The count of all browser chrome JS errors that were collected locally.

browser.errors.collected_with_stack_count
    The count of browser chrome JS errors that were collected locally and had
    a usable stack trace.

browser.errors.reported_success_count
    The count of all browser chrome JS errors that were reported to the
    remote collection service.

browser.errors.reported_failure_count
    The count of all browser chrome JS errors that we attempted to report to
    the remote collection service, but failed to.

browser.errors.sample_rate
    The sample rate at which collected errors were reported.

browser.errors.collected_count_by_filename
    The count of all browser chrome JS errors that were collected locally,
    keyed by the filename of the file in which the error occurred.
Data review for the new measures added.
Attachment #8958561 - Flags: review?(francois)
Comment on attachment 8958561 [details]
Data Collection Request

1) Is there or will there be **documentation** that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes, in Scalars.yml.

2) Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, telemetry setting.

3) If the request is for permanent data collection, is there someone who will monitor the data over time?**

Not permanent.

4) Using the **[category system of data types](https://wiki.mozilla.org/Firefox/Data_Collection)** on the Mozilla wiki, what collection type of data do the requested measurements fall under?  **

Category 1.

5) Is the data collection request for default-on or default-off?

Default-on in Nightly only

6) Does the instrumentation include the addition of **any *new* identifiers** (whether anonymous or otherwise; e.g., username, random IDs, etc.  See the appendix for more details)?

No

7) Is the data collection covered by the existing Firefox privacy notice?

Yes

8) Does there need to be a check-in in the future to determine whether to renew the data?

No, telemetry alerts are fine.
Attachment #8958561 - Flags: review?(francois) → review+
Priority: -- → P1
Comment on attachment 8958560 [details]
Bug 1444554: Add Telemetry scalars for BrowserErrorReporter.jsm.

:Gijs has approved the revision.
Chris H-C :chutten has approved the revision.

https://phabricator.services.mozilla.com/D725
Attachment #8958560 - Flags: review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/a760e111f2f157fbb18e66117f026ca298d4343e
Bug 1444554: Add Telemetry scalars for BrowserErrorReporter.jsm. r=Gijs,chutten
Pushed by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/803f2dfa6e12
Add Telemetry scalars for BrowserErrorReporter.jsm: update file after merge conflict CLOSED TREE
Backout by csabou@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/3d21d31141dc
Backed out changeset a760e111f2f1 for merge conflicts on browser_BrowserErrorReporter.js and failures after merging to autoland. a=backout
Backout by csabou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7db445828978
Backed out changeset 803f2dfa6e12 for keep failling on BrowserErrorReporter.jsm after the merge conflict. CLOSED TREE
Michael, please do not land known conflicting patch into different integration branches at the same time. Conflicts wouldn't be resolved automatically, and that would just confuse sheriff and make the tree closed for longer.
This bug has been backed out in https://hg.mozilla.org/integration/autoland/rev/6e5043e04b88f201eeceb59165d213bc4b8b15e8 for merge conflicts with bug 1445009.

Since it seems the tree is a bit messed up after some unsuccessful backout, I directly reverted the files to the previous revision before both changes.
Flags: needinfo?(mkelly)
https://hg.mozilla.org/mozilla-central/rev/a760e111f2f1
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
This is still backed out as per comment 15.
Status: RESOLVED → REOPENED
Flags: needinfo?(mkelly)
Resolution: FIXED → ---
https://hg.mozilla.org/mozilla-central/rev/bf74704e01c5
Status: REOPENED → RESOLVED
Closed: Last yearLast year
Resolution: --- → FIXED
See Also: → 1484776
Depends on: 1513567
You need to log in before you can comment on or make changes to this bug.