Telemetry data suggests between 13%-40% of errors being collected are from
builds older than a week. Since Nightly updates twice a day, errors from builds
that old don't reflect the current state of Nightly, so we can ignore them and
save some bandwidth.
A build is considered "recent" if the date encoded at the start of the
appBuildId (YYYYMMDD) is within 7 days of the current date. Since this is mostly
for preventing high load on the collection service, the check does not handle
problems with the local clock being inaccurate in order to simplify the
implementation.
MozReview-Commit-ID: BbCO4kaBprL
testFetchArguments and the add-on ID mangling tests already cover error
collection end-to-end, so no new tests are needed to cover testing the idle
callback.
MozReview-Commit-ID: DJrqT5jCq44
Also adds resource://devtools to the whitelist of reported paths for the
scalar.
Differential Revision: https://phabricator.services.mozilla.com/D831
MozReview-Commit-ID: BiAyoTQsWxx
Release is already included in the context as browser info and doesn't need to
be kept as a tag like appBuildId was.
Differential Revision: https://phabricator.services.mozilla.com/D807
MozReview-Commit-ID: IGzT3C3HSG
The transforms for turning an nsIScriptError into a payload that Sentry
understands were getting a bit complex for a single function, so they're
refactored into a list of transform functions that are applied in sequence to
produce the payload. This will make it easier to manage adding new transforms to
the list.
Refactoring this revaled a problem with the test code: it assumed that listeners
for console messages were notified in order of registration (since it used a
temporary listener to determine when the rest of the listeners had been notified
of a message). Changing the async evaluation of the code broke the tests, so
they had to be refactored as well.
Without a way to know when all console listeners have been notified, we can't
assert that a message will not be received by BrowserErrorReporter. We do two
things to get around this:
- Where possible, call `observe` directly on the reporter instance.
- Add constructor params for registering and unregistering listeners so we can
test that logic without relying on messages being received or not.
MozReview-Commit-ID: EEH6IROOuHD
The module attribute for an exception is surfaced in Sentry as the "transaction"
tag, and is useful for errors that don't include stack traces.
Differential Revision: https://phabricator.services.mozilla.com/D727
MozReview-Commit-ID: JKwgmE2jBXB
Along with adding source code, this updates the reported to more closely follow
the Sentry SDK docs:
- Remove the "request" payload, which is for reporting errors related to HTTP
requests.
- Include SDK info in the payload.
- Reverse the order of stack frames; they are meant to be ordered oldest to
newest.
- Include a local UTC timestamp in the payload.
- Remove the in_app flag from stack traces, as it's not required or useful in
the context of Firefox.
MozReview-Commit-ID: 558KrZNah6d
Differential Revision: https://phabricator.services.mozilla.com/D648
Errors are collected via nsIConsoleService, shaped to a Sentry-compatible
format, and sent off. Reporting is on by default, and can be disabled using a
checkbox added to the privacy prefs in about:preferences.
Collected errors are sampled to avoid overloading the collection service; the
sample rate was determined by a previous Shield study that measured the number
of errors occurring in Nightly.
The feature is hard-disabled outside of Nightly and local builds, and the
preference is disabled by default in local builds. It is intended as a prototype
that will be evaluated and replaced by a more robust collection system if it
proves helpful.
Differential Revision: https://phabricator.services.mozilla.com/D561
MozReview-Commit-ID: 6aqUatXyuYs
