Open Bug 486806 Opened 11 years ago Updated 1 year ago

Change to anchor href forces synchronous parse of the URI from inside SetAttr

Categories

(Core :: DOM: Core & HTML, defect, P5)

x86
macOS
defect

Tracking

()

People

(Reporter: bzbarsky, Unassigned)

Details

Right now, if someone sets one of the anchor part properties (hostname, host, hash, etc) on an HTMLAnchorElement, we'll end up creating the new nsIURI, then serializing it to a string and calling SetAttr.  See nsGenericHTMLElement::SetHrefToURI.

The problem is that SetAttr will call AttributeChanged, which will end up doing a HasAttributeDependentStyle check, which will construct the RuleProcessorData, which will query visited stat, which will reparse the string into a URI.

I added code in bug 485553 to cache the URI directly, but that needs to happen after the SetAttr call, so if the above codepath is hit we end up wasting time creating the nsIURI object anyway.

It would be kind of nice, for this case, to have a way to SetAttr with an nsAttrValue, maybe.  Or something.
Can you call SetAttrAndNotify? That's what we do for .style
Could you modify nsGenericElement::SetAttrAndNotify a bit, so that
AfterSetAttr is called before nsNodeUtils::AttributeChanged?
Then cache value in AfterSetAttr and use it in mutation observer (via AttributeChanged). Would that help here?

I think calling AfterSetAttr before nsNodeUtils::AttributeChanged
might be the right thing anyway. Mutation observers would then get access to
nsIContent object which has done whatever it is going to do with the attribute.
AfterSetAttr call could probably moved to happen even before binding->AttributeChanged.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.