Open
Bug 1334657
Opened 7 years ago
Updated 2 years ago
The Reset/ResetToURI stuff in nsDocument is a mess
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox54 | --- | affected |
People
(Reporter: bzbarsky, Unassigned)
References
Details
For example, ResetToURI has a codepath for the !aPrincipal case. But the only callers are nsDocument::CloneDocHelper (which definitely passes a principal) and nsDocument::Reset. nsDocument::Reset passes in the principal it got off the channel. I guess we could have somehow failed to get a principal from the channel, but just getting it from the URI in that case is pretty bizarre. For one thing, why would it work, when getting from the channel did not? Also, in Reset we null-check aChannel, and pass a null URI to ResetToURI if the channel is null. But ResetToURI then asserts it got a URI... I guess we do have a Reaset() caller that passes a null channel: URIUtils::ResetWithSource when aSourceNode is not an nsINode. Except it's already got an XXX comment about how what it's doing is bunk, and nsIDOMNode is not scriptable anyway, so all of its impls better QI to nsINode! We should really clean this up, remove dead codepaths, and maybe replace some failure cases with MOZ_CRASH instead of making up principals out of whole cloth...
Updated•7 years ago
|
Priority: -- → P3
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•