I'm working on an application that uses XPath expressions to select nodes from XML. We've noticed that this seems to break down for us when testing in the Microsoft Edge preview. I've cut down our code to a brief snippet that demonstrates the issue:
var xml = "<xml id='relationships'><Relationships><f id='some_id' ><f id='some_other_id' /></f></Relationships></xml>";
var doc = (new DOMParser).parseFromString(xml, "text/xml");
var nodes = doc.evaluate("//f[@id='some_id' and f]", doc, doc.createNSResolver(doc.documentElement), XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
console.log(nodes.snapshotLength);
In Chrome, this will log out 1
and the nodes.snapshotItem
will contain the correct node, but in Edge, it's logging out 0
and returning no nodes.
If I run either half of this condition separately, "//f[@id='some_id']"
or "//f[f]"
, it works consistently across browsers and Edge returns the correct node. It only fails when these two conditions, both true for the node in question, are combined with the and
. I'm not an XPath expert by any stretch, so can anyone tell me if I'm doing anything nonstandard within this snippet, or if this looks like an issue with the Edge preview's XPath implementation?
Update: This issue was resolved in the November 2015 update to Windows/Edge
This appears to be a bug with the current implementation in Microsoft Edge. I did notice, however, that if you flip the conditions around, the proper element is retrieved:
//f[f and @id='some_id']
For the time being, I hope this is an acceptable alternative. I am opening up a bug for our team to review on our end. Than you for helping us improve Microsoft Edge :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With