Last Comment Bug 312019 - Namespace and prefix lookup algorithms don't follow the spec
: Namespace and prefix lookup algorithms don't follow the spec
Status: RESOLVED DUPLICATE of bug 1061578
:
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.w3.org/TR/2004/REC-DOM-Lev...
: 342618 672033 (view as bug list)
Depends on:
Blocks: 672033
  Show dependency treegraph
 
Reported: 2005-10-11 01:30 PDT by Peter Van der Beken [:peterv]
Modified: 2015-10-27 04:34 PDT (History)
12 users (show)
jst: wanted‑next+
jst: blocking1.9.2-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch, v1 (2.82 KB, patch)
2006-06-24 14:54 PDT, Alex Vincent [:WeirdAl]
no flags Details | Diff | Review
tc1 - checking if lookupNamespaceURI retuns right uri (954 bytes, text/html)
2007-01-29 21:15 PST, Joao Eiras
no flags Details
tc2 - checking if XPathNSResolver works with XPathEvaluator.evaluate (1.01 KB, text/html)
2007-01-29 21:16 PST, Joao Eiras
no flags Details
tc3 - tsting for duplicate prefixes with different uri (895 bytes, text/html)
2007-01-29 21:16 PST, Joao Eiras
no flags Details
tc4 - checking if a XPathNamespaceResolver is live (940 bytes, text/html)
2007-01-29 21:17 PST, Joao Eiras
no flags Details

Description Peter Van der Beken [:peterv] 2005-10-11 01:30:44 PDT
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] 2005-10-15 23:50:46 PDT
Does bug 246604 impact this bug?
Comment 2 Alex Vincent [:WeirdAl] 2005-10-16 00:02:00 PDT
Also note bug 308478, which may be valid.
Comment 3 Alex Vincent [:WeirdAl] 2006-06-09 16:10:17 PDT
peterv: can you write a testcase demonstrating the broken behavior?
Comment 4 Alex Vincent [:WeirdAl] 2006-06-24 09:37:57 PDT
*** Bug 342618 has been marked as a duplicate of this bug. ***
Comment 5 Alex Vincent [:WeirdAl] 2006-06-24 09:38:54 PDT
See attachment 226925 [details] for a testcase.  :)
Comment 6 Martin Honnen 2006-06-24 09:43:28 PDT
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] 2006-06-24 09:47:07 PDT
Looks like collateral damage from the initial bug:  our impl. of isDefaultNamespace depends on LookupNamespaceURI doing the right thing.
Comment 8 Alex Vincent [:WeirdAl] 2006-06-24 10:06:15 PDT
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] 2006-06-24 14:54:53 PDT
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.
Comment 10 Peter Van der Beken [:peterv] 2006-06-26 18:12:28 PDT
(In reply to comment #8)
> after checking xmlns attrs

That's the opposite of what DOM Level 3 Core specifies.
Comment 11 Joao Eiras 2007-01-29 21:14:07 PST
I was going to report a bug on this, but this is it :P
I'll attach 4 tcs
Comment 12 Joao Eiras 2007-01-29 21:15:35 PST
Created attachment 253280 [details]
tc1 - checking if lookupNamespaceURI retuns right uri
Comment 13 Joao Eiras 2007-01-29 21:16:09 PST
Created attachment 253281 [details]
tc2 - checking if XPathNSResolver works with XPathEvaluator.evaluate
Comment 14 Joao Eiras 2007-01-29 21:16:54 PST
Created attachment 253282 [details]
tc3 - tsting for duplicate prefixes with different uri
Comment 15 Joao Eiras 2007-01-29 21:17:22 PST
Created attachment 253283 [details]
tc4 - checking if a XPathNamespaceResolver is live
Comment 16 Joao Eiras 2007-02-02 20:14:56 PST
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) 2009-06-26 15:22:58 PDT
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 2009-06-26 17:51:24 PDT
> 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) 2009-06-26 19:39:31 PDT
(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] 2009-06-27 02:17:56 PDT
(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) 2009-07-20 02:20:25 PDT
(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, jst@mozilla.com) 2009-07-22 17:47:31 PDT
Not critical for 1.9.2.
Comment 23 Peter Van der Beken [:peterv] 2011-08-16 09:36:16 PDT
*** Bug 672033 has been marked as a duplicate of this bug. ***
Comment 24 Peter Van der Beken [:peterv] 2015-10-27 04:34:25 PDT

*** This bug has been marked as a duplicate of bug 1061578 ***

Note You need to log in before you can comment on or make changes to this bug.