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...
Pushed by tritter@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2ee6c94f35b3 Infrastructure for causing a crash at most N times r=KrisWright,ckerschb https://hg.mozilla.org/integration/autoland/rev/83e5baac01a9 Wire up a crash for Javascript Load Telemetry r=ckerschb,Gijs
|
||
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
|
||
Pushed by tritter@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d7e4042af76c WIP: Bug 1723204: Infrastructure for causing a crash at most N times r=KrisWright,ckerschb,freddyb https://hg.mozilla.org/integration/autoland/rev/4a20d1832cf4 Wire up a crash for Javascript Load Telemetry r=ckerschb,Gijs https://hg.mozilla.org/integration/autoland/rev/df236c937895 Update tests to prevent crashes r=ckerschb,jdescottes,robwu
|
|
Assignee | |
Updated•3 years ago
|
Description
•