the local-name function uses prefixed names instead of local names

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a document with a prefixed element, i.e. <ns:element>
2. Output the local name of said element, i.e. evaluate("local-name(*)")

What is the expected output? What do you see instead?
The local-name should be "element", regardless of prefix used in the markup.
The local-name returned by wgxpath is "ns:element".
(compare http://www.w3.org/TR/xpath/#function-local-name)

What version of the product are you using? On what operating system?
wgxpath r20, IE11, Windows 7.

Please provide any additional information below.
I already found and test-hotfixed the relevant parts of the code, tho I only 
found the minimized version of it to work with.

Compare the 2 XPath functions local-name and name:

V("local-name",3,!1,!0,function(a,b){var c=b?Xa(b.a(a)):a.a;return 
c?c.nodeName.toLowerCase():""},0,1,!0)

V("name",3,!1,!0,function(a,b){var c=b?Xa(b.a(a)):a.a;return 
c?c.nodeName.toLowerCase():""},0,1,!0)

They are identical. "local-name" shouldn't access the "nodeName" property, but 
rather "localName" 
(http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-NodeNSLocalN).
When you replace local-name's "nodeName" with "localName", the testcase 
outlined above works as expected.


Additionally, selecting a prefixed element fails completely (i.e. evaluating 
"/ns:element" on the document above), the relevant code for that seems to be
K.prototype.a=function(a){var b=a.nodeType;return 
1!=b&&2!=b?!1:"*"!=this.h&&this.h!=a.nodeName.toLowerCase()?!1:this.c==(a.namesp
aceURI?a.namespaceURI.toLowerCase():"http://www.w3.org/1999/xhtml")};
Changing "nodeName" to "localName" here allows queries of the syntax 
"ns:element" to find something. The function looks a little bit too mystical to 
say what else this change would cause, so not sure about this one.

Original issue reported on code.google.com by Faulo...@gmail.com on 8 Apr 2014 at 5:36

[GoogleCodeExporter]

Well, I found the code. ^^'

http://code.google.com/p/wicked-good-xpath/source/browse/trunk/functionCall.js
Line 345:
  LOCAL_NAME: wgxpath.FunctionCall.createFunc_('local-name',
      wgxpath.DataType.STRING, false, true, false,
      function(ctx, opt_expr) {
        var node = opt_expr ? opt_expr.evaluate(ctx).getFirst() : ctx.getNode();
        return node ? node.nodeName.toLowerCase() : '';
      }, 0, 1, true),


I would just go ahead and fix this, but I'd like someone to verify that, yes, 
local-name SHOULD return DOM's localName instead of the potentially prefixed 
nodeName.

Original comment by Faulo...@gmail.com on 8 Apr 2014 at 5:50

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Thanks for the report. Please attach a sample HTML page to this issue on which 
the bug can be reproduced.

Original comment by gden...@google.com on 8 Apr 2014 at 8:10

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Here you go.

This HTML page contains some prefixed nodes, and then outputs their respective 
local-names and names.
As a bonus, each node tries to query itself using the syntax 
"self::ns:element", which doesn't work in wgxpath and seems to be related to 
this local-name thing.

The output in Firefox, Chrome and Opera is:
<wgx:element>
  [object Element]
  XPath local-name():
    element
  DOM localName:
    element
  XPath name():
    wgx:element
  DOM nodeName:
    wgx:element
  XPath self::wgx:element:
    [object Element]

(Which, as far as I can tell, is in accordance with the spec.)

Whereas the output in IE11 is:

<wgx:element>
  [object Element]
  local-name():
    wgx:element
  DOM localName:
    element
  name():
    wgx:element
  DOM nodeName:
    wgx:element
  self::wgx:element:
    null

(I am especially bugged by the last point, since that is what is currently 
breaking my app. ^^')

Thanks for looking into this!

Original comment by s...@ibp-dresden.de on 9 Apr 2014 at 10:52

• Added labels: ****
• Removed labels: ****

Attachments:

• wgxpath.test.xhtml

[GoogleCodeExporter]

(Ah, that last comment was by me, forgot to switch accounts, sorry. ^^')

Original comment by Faulo...@gmail.com on 9 Apr 2014 at 11:11

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

For this bug to be exhibited the document has to be XML (like XHTML) not HTML, 
so this falls partially under the "support for XML documents" feature request. 
This is fairly low-hanging fruit to fix, though, so I'll do it, and then maybe 
make further progress toward completing that feature request.

Original comment by gden...@google.com on 9 Apr 2014 at 2:47

• Changed state: Accepted
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

...oh. Sorry, it's been a while since I've worked with text/html, I wasn't even 
aware that XPath's functions (or the DOM attributes related to them) behave 
differently there.

For the sake of completion, here is the same test case as HTML. Here, wgxpath 
does indeed behave almost identical to the XPath Implementations of Firefox and 
company.
Namely, the namespace prefix is part of the local name, and querying by prefix 
doesn't work. Differences in upper/lowercase fall under HTML's YOLO philosophy, 
I guess.

Original comment by Faulo...@gmail.com on 9 Apr 2014 at 3:57

• Added labels: ****
• Removed labels: ****

Attachments:

• wgxpath.test.html

[GoogleCodeExporter]

Fixed in the latest install file.

Original comment by gden...@google.com on 22 Jul 2014 at 5:35

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****