278737 - Investigate removing nsIContent::GetExistingAttrNameFromQName

Status: NEW

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

Description

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

The only two clients of that function are nsDOMAttributeMap and the xul persist
code (in nsXULDocument::Persist and nsXULContentBuilder::AddPersistentAttributes). 

GetExistingAttrNameFromQName is mostly a convinience function and a speed
optimization, so it might very well be possible to remove it. nsDOMAttributeMap
is surly not performance critical, and the Persist code might not be either.

If we do remove this function we should remove the one-slot nsNodeInfo cache as
well since this should be the only situation where we create temporary nsNodeInfos.

Comment 1

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

An alternative to the function could be a helperfunction in nsContentUtils. The
advantage of having some sort of helping function around is that it makes it
easier to support namespaced attributes properly in various places.

Comment 2

[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.

Comment 3

[Olli Pettay [:smaug][[e-mail]] (holiday -> Aug30)]

Element::GetExistingAttrNameFromQName, as it is these days, is indeed a bit odd.
It returns a nodeinfo, yet the method name hints about AttrName.

(AttrArray::GetExistingAttrNameFromQName does what one would expect it to do.)

So, still a valid bug.