Bug 22958 – Attribute namespaces are serialized as if they were element ones

• Component: DOM
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

If an attribute is created with setAttributeNS(), its namespace is printed as if it were a default one.

On the attached test, two default namespaces are printed.

[Alexey Proskuryakov]

Created attachment 26197 [details]
test case

[Alexey Proskuryakov]

*** Bug 58221 has been marked as a duplicate of this bug. ***

[Leo B]

Still seeing essentially same problem in Google Chrome Version 26.0.1410.43 m.

As verified in the developer tools debugger, in scope variables, setAttributeNS does this:

For the element creates an attribute, but the attribute's namespaceURI is null.

And for the element it creates a second attribute that hasn't been asked for, of name xmlns with value being what should have been the namespaceURI of the attribute that has been asked for.

The solution / workaround is:  Pass in a qualified name and it will work!  For most compatibility, you probably should get the prefix with yourElement.lookupPrefix(yourNamespaceURI).

Workaround found by paying attention to http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-ElSetAttrNS where it says the second parameter is the qualifiedName, the qualified name of the attribute to create or alter.

Problem found when running new tests in http://srguiwiz.github.com/adj-js/user-docs/tests.html and it failed in Chrome as a consequence of setAttributeNS behavior.  It had passed in Firefox.  Since then fixed http://srguiwiz.github.com/adj-js/user-docs/ to use qualified name, now it works in Chrome as well.

Does this workaround and the specification mean this isn't a bug any more?

[Alex Milowski]

(In reply to comment #3)

> 
> Does this workaround and the specification mean this isn't a bug any more?

This is still a bug.  The DOM API allows for the case where the prefix is not specified.  In such cases, the serializer needs to generate a prefix.

In my testing, the serializer clearly assumes the prefix property will be present.  The extra default namespace comes from the attempt to declare the prefix used for the namespace attribute.  When the prefix is not specified and there needs to be a prefix, the wrong thing happens.

I have a simple example the demonstrates the problem that I will attach.

[Alex Milowski]

Created attachment 204774 [details]
A example that demonstrates the different possible ways to cause and/or fix the problem.

Note: In Firefox, you aren't allowed to set the prefix.  This is clearly a DOM bug for them as [1] says you are allowed to set the prefix. 

[1] http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-NodeNSPrefix

[Alex Milowski]

Looking at the source, the problem is two fold:

  1. A prefix is not generated for the qualified name when it is missing.

  2. The attribute prefix, when set, is not passed properly to appendNamespace().


For (1), at MarkupAccumulator.cpp:455:
 
       QualifiedName prefixedName = attribute.name();
        if (attribute.namespaceURI() == XLinkNames::xlinkNamespaceURI) {
            if (!attribute.prefix())
                prefixedName.setPrefix(xlinkAtom);
        } else if (attribute.namespaceURI() == XMLNames::xmlNamespaceURI) {
            if (!attribute.prefix())
                prefixedName.setPrefix(xmlAtom);
        } else if (attribute.namespaceURI() == XMLNSNames::xmlnsNamespaceURI) {
            if (attribute.name() != XMLNSNames::xmlnsAttr && !attribute.prefix())
                prefixedName.setPrefix(xmlnsAtom);
        }
        result.append(prefixedName.toString());

There are an infinite number of cases that need to be handled here by a check for:

   } else if (attribute.namespaceURI() && !attribute.prefix()) {
       // generate a prefix ...
   }

and that is missing.

For (2), the actually prefix used (either what was set or what was given) needs to be tracked and passed later on to appendNamespace() instead of attribute.prefix() as that field may remain null in the case of generated or set prefixes.

Because you have to generate namespaces, it is unclear to me as of yet whether the current method of tracking in-scope namespaces will work properly.

[Alex Milowski]

Bug 117764 is related to this problem.

[Rob Buis]

Committed r154779: <http://trac.webkit.org/changeset/154779>

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.