783003 - Xpath query with name() is not working

Status: RESOLVED INVALID

(Core :: XSLT, defect)

Description

[Dylan Barrell]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8) AppleWebKit/536.10.3 (KHTML, like Gecko) Version/5.2 Safari/536.10.3

Steps to reproduce:

Extension not working as it previously worked


on the following page:

http://www.deque.com/products/product-overview

execute the following code in the JavaScript shell (Firebug console)

var str = "//*[name()='h1' or name()='h2' or name()='h3' or name()='h4' or name()='h5' or name()='h6' or @role='heading']";
var nodesIter = document.evaluate( str, document, null, XPathResult.ORDERED_NODE_ITERATOR_TYPE, null);
nodesIter.iterateNext();



Actual results:

iterateNext() returns null


Expected results:

Should have returned an h1 node

Comment 1

[mjh563]

It works OK if you use 'H1' instead of 'h1'.

Comment 2

[Ioana (away)]

Dylan, you said yourself that this is a Firebug problem ("Extension not working as it previously worked"). Since it's not a Firefox problem, I will mark the bug as Invalid.

If you want this fixed, please contact the extension developers.

Comment 3

[Dylan Barrell]

Dude, seriously...it is NOT a Firebug problem. I did NOT say its a Firebug problem. It is a problem in MY extension, for which I am the developer. I was kind enough to find some source code that allows YOU, or any causal, interested observer, to reproduce it using the JavaScript shell of your liking. Including, if you so please, Firebug.

Did you try to execute that code? Did you do any due diligence prior to marking this bug as INVALID, other than making some false assumptions?

Comment 4

[mjh563]

I'm not that familiar with XPath, but it appears to normalise name() to uppercase in HTML documents, like Node.nodeName does.

Are you sure that code used to work? Which was the last Firefox version you can reproduce the 'Expected results' in?

Comment 5

[Dylan Barrell]

Last version I can validate this in is 3.6

Comment 6

[mjh563]

I'm not sure if it's a valid bug or not. Try moving it to

Product: Core
Component: XSLT

then hopefully someone who's more familiar with XPath will see it and comment.

Comment 7

[mjh563]

Attachment: Testcase showing different results in Firefox 3.6 and 16

This testcase demonstrates the issue. It displays '[object HTMLParagraphElement]' in Firefox 3.6, but 'null' in Firefox 16.

Comment 8

[mjh563]

Google Chrome and Opera both return the node. So it does appear to be a regression in Firefox > 3.6.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Unfortunately the XSLT working group at W3C has been very reluctant to define the interactions between HTML and XSLT. So the XPath and XSLT specs leave this completely undefined.

So when we worked on this area for HTML5 we defined some of the interactions between HTML and XSLT/XPath in that spec instead. You can see the result here:

http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#interactions-with-xpath-and-xslt

Unfortunately that doesn't define interactions for the name() and local-name() functions. Not sure why since I seem to recall discussing that.

Either way, we decided to make name() and local-name() match .nodeName and .localName in Firefox. If you think that should be changed please file a bug on the HTML5 spec to have it clarified what the proper behaviour should be.

Comment 10

[Dylan Barrell]

Excellent!! Righto...maybe I'll just use Chrome...

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Because that is clearly a better solution than having a standardized behavior that works across all browsers?