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)

defect

Tracking

()

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...
Priority: -- → P3
Depends on: 1489308
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.