Differences in Xpath evalution between Chrome and Firefox
Reported by
michael....@gmail.com,
Jul 4 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Steps to reproduce the problem: 1. Run code snippet on http://stackoverflow.com/questions/37964191/differences-in-xpath-evalution-between-chrome-and-firefox/37964939?noredirect=1#comment63766969_37964939 What is the expected behavior? Evaluation of count is not consistent with other browsers. What went wrong? These xpath snippets are not evaluating correctly: (//table)[count((//table)[5]/descendant::th)] ((//table)[2]/tbody/tr[1]/td)[count((//table)[2]/descendant::th[.='TextField']/preceding-sibling::th)+1] The example html that I am running them against can be found in the stack overflow question: http://stackoverflow.com/questions/37964191/differences-in-xpath-evalution-between-chrome-and-firefox/37964939?noredirect=1#comment63766969_37964939 Did this work before? N/A Chrome version: 51.0.2704.106 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 22.0 r0
,
Jul 5 2016
,
Jul 25 2016
dominicc@ thoughts?
,
Jul 26 2016
I can reproduce this on Linux 52.0.2743.82 (Official Build) (64-bit); I can't imagine any platform specifics here so broadening. This looks like a bug; I've been playing around with the first expression here: http://jsbin.com/gupaqojopi/1/edit?html,output TL;DR: count((//table)[2]/descendant::th)-3 evaluates to 3; (//table)[3] evaluates to a table element; but (//table)[count((//table)[2]/descendant::th)-3] evaluates to null. So there's some problem evaluating that expression. I did not poke at the second expression but it has some similar aspects. I believe Blink has two XPath implementations; this one is the one in core/xml/XPathExpression, etc. I'd probably try debugging this and dumping the XPath expression to see just how that index was parsed.
,
Aug 26 2016
I would hope chromium would also have an additional 'Full Xpath' not abbreviated Xpath. https://www.youtube.com/watch?v=ohY815wUz9o
,
Aug 29 2016
I'm not sure what you mean by "full" XPath. It is unlikely we would implement a newer XPath specification. However having one implementation, instead of two, which is compatible with other browsers is a reasonable goal.
,
Feb 22 2017
Any updates here?
,
Mar 27 2017
Only that some other compatibility issues have come to light in the meantime, like Issue 648587 and Issue 651757 .
,
Mar 28 2017
Also works in Edge 14 (BrowserStack). WebKit based browsers fail, the rest work.
,
Aug 7 2017
This is still an issue on the latest versions of Chrome [Version 59.0.3071.115 (Official Build) (64-bit)] and chromedriver [ChromeDriver 2.31.488763 (092de99f48a300323ecf8c2a4e2e7cab51de5ba8)]. I can confirm this still works fine on Firefox. Is there any ETA on when this will be fixed?
,
Jan 15 2018
Bulk edit bugs owned by dominicc@
,
Jan 15
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by timloh@chromium.org
, Jul 5 2016