Skip parsing a URI to look for a password the spec cannot hold
Categories
(DevTools :: Console, enhancement)
Tracking
(firefox157 fixed)
| Tracking | Status | |
|---|---|---|
| firefox157 | --- | fixed |
People
(Reporter: mayankleoboy1, Assigned: mayankleoboy1)
References
Details
Attachments
(1 file)
| Assignee | ||
Comment 1•27 days ago
|
||
Console and nsScriptError both build an nsIURI out of a script filename on
every message, purely to ask whether it carries a password worth hiding. On
the console.clear() testcase in the bug that parse is 19% of the content
process main thread.
A password only reaches nsIURI through a userinfo component, and every
implementation that can report a non-empty one - nsStandardURL, DefaultURI,
and SubstitutingJARURI, which forwards to its source URL - derives it from a
literal '@'. Scanning for that byte first leaves the sanitizing path
unchanged and skips the parse otherwise.
Both call sites now share NS_GetSanitizedSpecFromSpec rather than spelling
the same check two different ways. That unifies one behaviour difference: on
a spec that has a password which cannot be hidden, Console used to fall back
to the raw spec, and nsScriptError to an empty string. The helper keeps
nsScriptError's behaviour, since emitting a spec known to contain a password
is the one outcome worth avoiding.
Console also had an NS_IsMainThread() check in front of the sanitizing,
added by bug 1246091 in 2016 when this code first became reachable from
workers and NS_NewURI was main thread only. Bug 1536744 renamed
NS_NewURIOnAnyThread to NS_NewURI in 2019, and nsIURI is immutable and
threadsafe, so the check has been dead weight since then. Dropping it also
means worker console events reaching a chrome console event handler - via
setConsoleEventHandler or retrieveConsoleEvents - get the same sanitizing
main thread ones already got.
Updated•27 days ago
|
Comment 3•26 days ago
|
||
| bugherder | ||
Updated•13 days ago
|
Description
•