Namespace and prefix lookup algorithms don't follow the spec

RESOLVED DUPLICATE of bug 1061578

Status

()

Core
DOM: Core & HTML
RESOLVED DUPLICATE of bug 1061578
12 years ago
2 years ago

People

(Reporter: peterv, Unassigned)

Tracking

Trunk
Points:
---
Bug Flags:
wanted-next +
blocking1.9.2 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments)

(Reporter)

Description

12 years ago
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.  :)

Comment 6

11 years ago
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
Created attachment 226939 [details] [diff] [review]
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.
(Reporter)

Comment 10

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

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

Comment 11

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

Comment 12

11 years ago
Created attachment 253280 [details]
tc1 - checking if lookupNamespaceURI retuns right uri

Comment 13

11 years ago
Created attachment 253281 [details]
tc2 - checking if XPathNSResolver works with XPathEvaluator.evaluate

Comment 14

11 years ago
Created attachment 253282 [details]
tc3 - tsting for duplicate prefixes with different uri

Comment 15

11 years ago
Created attachment 253283 [details]
tc4 - checking if a XPathNamespaceResolver is live

Comment 16

11 years ago
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 ?

Updated

9 years ago
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

Comment 18

8 years ago
> 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.

Updated

8 years ago
Flags: blocking1.9.2?
(Reporter)

Comment 20

8 years ago
(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-
Blocks: 672033
(Reporter)

Updated

6 years ago
Duplicate of this bug: 672033
Assignee: ajvincent → nobody
(Reporter)

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1061578
You need to log in before you can comment on or make changes to this bug.