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

Status: NEW

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

Description

[Boris Zbarsky [:bzbarsky]]

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.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Can you call SetAttrAndNotify? That's what we do for .style

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 3

[Firefox Bug Husbandry Bot]

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.