Xpath query with name() is not working




6 years ago
5 years ago


(Reporter: Dylan Barrell, Unassigned)


14 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)



(1 attachment)



6 years ago
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:


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);

Actual results:

iterateNext() returns null

Expected results:

Should have returned an h1 node

Comment 1

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

Comment 2

6 years ago
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.
Last Resolved: 6 years ago
Resolution: --- → INVALID

Comment 3

6 years ago
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?
Resolution: INVALID → ---

Comment 4

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

6 years ago
Last version I can validate this in is 3.6

Comment 6

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

6 years ago
Created attachment 661800 [details]
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.


6 years ago
Attachment #661800 - Attachment mime type: text/plain → text/html

Comment 8

6 years ago
Google Chrome and Opera both return the node. So it does appear to be a regression in Firefox > 3.6.
Component: Untriaged → XSLT
Product: Firefox → Core
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:


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

6 years ago
Excellent!! Righto...maybe I'll just use Chrome...
Because that is clearly a better solution than having a standardized behavior that works across all browsers?


5 years ago
Last Resolved: 6 years ago5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.