Collect additional data on difficult-to-reproduce occurrances
Categories
(Firefox :: Security, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox93 | --- | fixed |
People
(Reporter: tjr, Assigned: tjr)
References
Details
Attachments
(3 files)
We are logging telemetry for JavaScript loads that do not fit the expected chrome://, resource:// type of loads.
JavaScript load telemetry for 92 Nightly - for Windows-only[0] - shows
- 2 users triggering 7 times on 'other'
- 12 users triggering 90 times on 'other-on-worker'
- 32 users triggering 606 times on a data url
- 36 user triggering 37 time on about:preferences
- 90 users triggering 141 times on about:downloads
After trynig to reproduce the about:preferences and about:downloads occurrances I cannot. I am not sure what additional information I could obtain through telemetry that would let me track down these instances except a stack trace. I am not 100% certain a stack trace would help, but it's my current best idea.
Delivering a stack trace without crashing is possible but would require a custom ping of some kind. An alternative is to just crash. These would be parent process crashes so they would bring down the whole browser unfortunately. We should be able to ensure a user would only crash at most once though.
[0] Windows has special additional telemetry details that allows us to separate out the Firefox Translation Telemetry Events (Bug 1722775) from the ones we are investigating here.
Assignee | ||
Comment 1•3 years ago
|
||
Assignee | ||
Comment 2•3 years ago
|
||
There's no way we could land this before Bug 1722775 because that would cause crashes for Translation users.
Assignee | ||
Comment 3•3 years ago
|
||
Assignee | ||
Comment 4•3 years ago
|
||
I confirmed the patches work (mostly?) as intended in a local build - the pref is updated and we crash. Then we don't anymore. The only thing I'm not certain about is that the crashes don't show up in about:crashes...
Comment 7•3 years ago
|
||
Backed out 2 changesets (Bug 1723204) for causing xpcshell failures in ValidateScriptFilename
Backout link: https://hg.mozilla.org/integration/autoland/rev/ca61528fd6031ba92797be0f1a757b29a161c28d
Push with failures, failure logs:
Assignee | ||
Comment 8•3 years ago
|
||
This is most commonly as a result of CU.evalInSandbox which
allows an arbitrary filename but when omitted will default
to the filename of the test, which is a filesystem path
and thus is disallowed.
Depends on D121417
Updated•3 years ago
|
Updated•3 years ago
|
Comment 9•3 years ago
|
||
Backed out 4 changesets (bug 1724220, bug 1723204) for causing cpp non-unified bustages in TestSmartCrashTrimmer.cpp.
https://hg.mozilla.org/integration/autoland/rev/8cd007fdbd4bf5f9cf8f5aa94413015b2bc388c4
Push with failures:
https://treeherder.mozilla.org/jobs?repo=autoland&revision=0dab9553a2a844bc574696d6eb10bf08fa3dcc98&selectedTaskRun=JjS05PuMRbidAnbroSOpCQ.0
Failure log:
https://treeherder.mozilla.org/logviewer?job_id=349370076&repo=autoland&lineNumber=6345
Comment 10•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6b6c21180ed9
https://hg.mozilla.org/mozilla-central/rev/0310d86a37b5
https://hg.mozilla.org/mozilla-central/rev/6614bd9a8b01
Comment 11•3 years ago
|
||
Assignee | ||
Updated•3 years ago
|
Description
•