Remove the `network.jar.channel` telemetry event
Categories
(Core :: Networking: JAR, task, P2)
Tracking
()
People
(Reporter: zbraniecki, Assigned: zbraniecki)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Attachments
(1 obsolete file)
In bug 1675205 we added a telemetry event to try to see if we can see zery byte length JAR channel loads.
In tree months of monitoring that probe we didn't see any correlation between that and YSOD events.
All URLs that are reported are like the following:
- "uBlock0@raymondhill.net.xpi!/web_accessible_resources/empty?secret=xxxxx"
- "%7B7a73dc4b-1b38-yyyy-xxxx-7d356dd4af34%7D.xpi!/blank.html"
- "adnauseam@rednoise.org.xpi!/web_accessible_resources/empty?secret=XXXXX"
- "%7B91f05833-bab1-xxxx-yyyy-187091a4d75d%7D.xpi!/panel/js/katalon/kar-extra.js"
with the uBlock0
one being by far the most common.
Since every day we see a steady flow of YSOD events on all channels, and none of the JAR events correspond to any of the UI XUL files or DTD files that may be causing the YSOD,
my conclusion is that, assuming the telemetry probe is capturing all cases of empty JAR Channel loads, that the JAR channel is below the layer where the source of the YSOD happens, and we need to look higher in the stack.
I filed a number of bugs blocking bug 1675823 to ensure we are casing a wide net on file types in their respective parsers, and once we see the full picture of which file types are affected, we'll likely either look in Chrome Protocol or Resource Protocol next.
Assignee | ||
Comment 1•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Description
•