Closed Bug 312019 Opened 14 years ago Closed 4 years ago

Namespace and prefix lookup algorithms don't follow the spec

Categories

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

defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1061578

People

(Reporter: peterv, Unassigned)

References

()

Details

Attachments

(5 files)

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.
Does bug 246604 impact this bug?
Also note bug 308478, which may be valid.
peterv: can you write a testcase demonstrating the broken behavior?
*** Bug 342618 has been marked as a duplicate of this bug. ***
See attachment 226925 [details] for a testcase.  :)
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>
Looks like collateral damage from the initial bug:  our impl. of isDefaultNamespace depends on LookupNamespaceURI doing the right thing.
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().
Assignee: general → ajvincent
Attached patch patch, v1Splinter Review
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.
(In reply to comment #8)
> after checking xmlns attrs

That's the opposite of what DOM Level 3 Core specifies.
I was going to report a bug on this, but this is it :P
I'll attach 4 tcs
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 ?
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
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
> 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
(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.
Flags: blocking1.9.2?
(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.
(In reply to comment #20)
> Please file a separate bug for that, it's unrelated to this one.

I filed bug 505178.
Not critical for 1.9.2.
Flags: wanted-next+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
Duplicate of this bug: 672033
Assignee: ajvincent → nobody
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1061578
You need to log in before you can comment on or make changes to this bug.