[Webkit-unassigned] [Bug 68679] REGRESSION(87010): elements in ECMA-cloud neither filled nor blurred - crash on Chromium

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=68679





--- Comment #9 from Tim Horton <timothy_horton at apple.com>  2011-09-27 17:59:21 PST ---
Is there any reason we actually care about the prefix? By the time it gets to isSupportedAttribute, it's a QualifiedName, which is a triple{prefix, name, namespace}. It seems to me that we only care about the name and the namespace; something earlier than us has already taken care of mapping the prefix to the namespace.

As a test, I did two things:

Change SVGURIReference::addSupportedAttributes to just:

>    void SVGURIReference::addSupportedAttributes(HashSet<QualifiedName>& supportedAttributes)
>    {
>      supportedAttributes.add(XLinkNames::hrefAttr);
>    }

In SVGGradientElement::isSupportedAttribute (because the element with the xlink on it in our example here is a gradient):

>    QualifiedName attrNameWithoutPrefix(attrName);
>    attrNameWithoutPrefix.setPrefix(nullAtom);

And then supportedAttributes.contains(attrNameWithoutPrefix).

Effectively, only having the namespaced (non-prefixed) version of the attribute name in supportedAttributes, and dropping the prefix from the attribute before checking it. This fixes our bug, and I double checked to make sure that it is still matching on the namespaces (it is).

So that might be a valid fix.

Is there an earlier place where we could strip the prefix instead of touching every single isSupportedAttribute? I haven't decided yet.

I don't see why we should care about the prefix at all. Just the namespace.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.