312019 - Namespace and prefix lookup algorithms don't follow the spec

Status: RESOLVED DUPLICATE of bug 1061578

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

Description

[Peter Van der Beken [:peterv]]

nsContentUtils::LookupNamespaceURI and nsNode3Tearoff::LookupPrefix don't
actually implement the lookup algorithms from the DOM spec: they only look for
xmlns attributes but they need to take into account element's namespaces that
aren't declared with xmlns attributes.

Comment 1

[Alex Vincent [:WeirdAl]]

Does bug 246604 impact this bug?

Comment 2

[Alex Vincent [:WeirdAl]]

Also note bug 308478, which may be valid.

Comment 3

[Alex Vincent [:WeirdAl]]

peterv: can you write a testcase demonstrating the broken behavior?

Comment 4

[Alex Vincent [:WeirdAl]]

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

Comment 5

[Alex Vincent [:WeirdAl]]

See attachment 226925 [details] for a testcase.  :)

Comment 6

[Martin Honnen]

The method isDefaultNamespace is also not working properly for a document created with W3C DOM Level 2 document.implementation.createDocument:
<http://home.arcor.de/martin.honnen/mozillaBugs/domLevel3/isDefaultNamespace1.html>

Comment 7

[Alex Vincent [:WeirdAl]]

Looks like collateral damage from the initial bug:  our impl. of isDefaultNamespace depends on LookupNamespaceURI doing the right thing.

Comment 8

[Alex Vincent [:WeirdAl]]

Here's a rough outline of how I think we can fix this:

For nsContentUtils::LookupNamespaceURI, after checking xmlns attrs, we could check content->mNodeInfo->GetPrefix() against the fed value.  If we have a match, aReturn becomes content->mNodeInfo->GetNamespaceURI().

For nsNode3Tearoff::LookupPrefix, after checking xmlns attrs, we check content->mNodeInfo->GetNamespaceURI() against the fed value.  If we have a match, aPrefix becomes content->mNodeInfo->GetPrefix().

Comment 9

[Alex Vincent [:WeirdAl]]

Attachment: patch, v1

This patch fixes the problem Martin's testcase covers, but I don't like it for two reasons.

(1) It doesn't fix the problem for undeclared attributes:

element.setAttributeNS("http://verbosio.mozdev.org/", "vb:foo", "foo");

nsDOMAttribute blindly forwards to nsGenericElement or nsContentUtils for these.

(2) LookupPrefix is implemented on nsNode3Tearoff, while LookupNamespaceURI is implemented on nsContentUtils.  This doesn't make much sense.

Thoughts?  smaug has suggested moving LookupPrefix to nsContentUtils, and changing nsContentUtils::LookupNamespaceURI to take nsINode instead of nsIContent.

Comment 10

[Peter Van der Beken [:peterv]]

(In reply to comment #8)
> after checking xmlns attrs

That's the opposite of what DOM Level 3 Core specifies.

Comment 11

[Joao Eiras]

I was going to report a bug on this, but this is it :P
I'll attach 4 tcs

Comment 12

[Joao Eiras]

Attachment: tc1 - checking if lookupNamespaceURI retuns right uri

Comment 13

[Joao Eiras]

Attachment: tc2 - checking if XPathNSResolver works with XPathEvaluator.evaluate

Comment 14

[Joao Eiras]

Attachment: tc3 - tsting for duplicate prefixes with different uri

Comment 15

[Joao Eiras]

Attachment: tc4 - checking if a XPathNamespaceResolver is live

Comment 16

[Joao Eiras]

If you don't mind a question:
the spec says the behaviour of passing null to lookupnamespaceURI is undefined.
How about returning the default namespace for that one ?

Comment 17

[nanto_vi (TOYAMA Nao)]

Since bug 468708 was fixed, the namespace of HTML elements is now "http://www.w3.org/1999/xhtml".  But HTMLElement.lookupNamespaceURI(null) still returns null.  This behavior differs from WebKit, which correctly returns "http://www.w3.org/1999/xhtml", and can break some scripts that assume lookupNamespace(null) returns the default namespace, such as AutoPagerize [1].

(In reply to comment #16)
> the spec says the behaviour of passing null to lookupnamespaceURI is undefined.
> How about returning the default namespace for that one ?

The spec [2] says, "If this parameter is null, the method will return the default namespace URI if any."

[1] http://userscripts.org/scripts/show/8551
[2] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Node3-lookupNamespaceURI

Comment 18

[Joao Eiras]

> The spec [2] says

The dom 3 xpath specs says otherwise, so there are two specs with similar behaviors although conflicting.
http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#XPathNSResolver-lookupNamespaceURI

Comment 19

[nanto_vi (TOYAMA Nao)]

(In reply to comment #18)

OK, It is not necessarily a bug that XPathNSResolver.lookupNamespaceURI(null) doesn't return the default namespace of a node from which the resolver is created, but it is a bug that Node.lookupNamespaceURI(null) doesn't return the default namespace of the node.  These two methods are indeed different though they have the same name.  Consider:

  document.implementation.createDocument('http://example.org/', 'foo', null)
          .documentElement.lookupNamespaceURI(null)

This should return "http://example.org/" per DOM 3 Core spec since it calls the lookupNamespaceURI method of the Node interface, not of the XPathNSResolver interface.  But Mozilla doesn't do so.

Comment 20

[Peter Van der Beken [:peterv]]

(In reply to comment #17)
> Since bug 468708 was fixed, the namespace of HTML elements is now
> "http://www.w3.org/1999/xhtml".  But HTMLElement.lookupNamespaceURI(null) still
> returns null.  This behavior differs from WebKit, which correctly returns
> "http://www.w3.org/1999/xhtml", and can break some scripts that assume
> lookupNamespace(null) returns the default namespace, such as AutoPagerize [1].

Please file a separate bug for that, it's unrelated to this one.

Comment 21

[nanto_vi (TOYAMA Nao)]

(In reply to comment #20)
> Please file a separate bug for that, it's unrelated to this one.

I filed bug 505178.

Comment 22

[Johnny Stenback (:jst)]

Not critical for 1.9.2.