Bug 12340 - XPathEvaluator behavior does not match Firefox - name() and attribute nodes
Summary: XPathEvaluator behavior does not match Firefox - name() and attribute nodes
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: XML (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Alexey Proskuryakov
URL:
Keywords:
Depends on:
Blocks: 10489
  Show dependency treegraph
 
Reported: 2007-01-19 22:31 PST by Jesse Costello-Good
Modified: 2007-01-29 10:16 PST (History)
0 users

See Also:


Attachments
proposed fix (7.68 KB, patch)
2007-01-27 12:37 PST, Alexey Proskuryakov
no flags Details | Formatted Diff | Diff
proposed fix (7.60 KB, patch)
2007-01-28 04:55 PST, Alexey Proskuryakov
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Costello-Good 2007-01-19 22:31:19 PST
// #2
// function name() does not work with attribute nodes

var strXML = '<data><record id="-a-" a="v">???</record><record
id="a-a">{abc}</record></data>';
var doc = (new DOMParser()).parseFromString(strXML, "text/xml");
var xpe = new XPathEvaluator();
var objResult = xpe.evaluate("//@*[name()='id']", doc, null, 0, null);
var itm = null;
var objNodes = [];
while (itm = objResult.iterateNext()) objNodes.push(itm);

assertEquals(2, objNodes.length); // Safari yields 0
Comment 1 Alexey Proskuryakov 2007-01-27 12:37:20 PST
Created attachment 12715 [details]
proposed fix
Comment 2 Alexey Proskuryakov 2007-01-28 04:55:11 PST
Created attachment 12723 [details]
proposed fix

Changed the wording of comments in the test a bit - the way name() works with a document that didn't have namespace normalization applied to it may be actually correct (at least, I couldn't find any indication that XPathEvaluator is supposed to normalize the document itself).
Comment 3 Darin Adler 2007-01-28 18:19:53 PST
Comment on attachment 12723 [details]
proposed fix

r=me

Should that be prefix.isEmpty() instead of prefix.isNull()? Is it possible to construct a test that would behave differently depending on which you used?

In general, I recommend taking advantage of the null value as distinct from empty only when it's necessary, so if either would work the same I'd prefer isEmpty.
Comment 4 Alexey Proskuryakov 2007-01-29 10:16:42 PST
Committed revision 19226.

(In reply to comment #3)
> Should that be prefix.isEmpty() instead of prefix.isNull()? Is it possible to
> construct a test that would behave differently depending on which you used?

I don't know how to make such a test; changed to isEmpty().