New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 648587 link

Starred by 4 users
Status: WontFix
Owner:
█ dominicc@chromium.org
Last visit > 30 days ago
Closed: Mar 2017
Cc:
█ rnimmagadda@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 3
Type: Bug



Sign in to add a comment

XPath locator with ".." and filtering predicate doesn't work

Reported by ekunguro...@gmail.com, Sep 20 2016 
UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0

Steps to reproduce the problem:
1. open DevTools
2. press Ctrl+F to find element
3. try to use //body/div/..[1=1] locator
4. try to use //body/div/parent::*[1=1] locator

What is the expected behavior?
Both locators should find the same element.

What went wrong?
The "//body/div/..[1=1]" locator doesn't find any element.

Did this work before? N/A 

Chrome version: 53.0.2785.116 (Official Build) m (32-bit)  Channel: stable
OS Version: 6.3
Flash Version: Shockwave Flash 23.0 r0

Affects also Selenium tests. Example is somewhat hypothetical, in real world it would be filtering condition inside parenthesis.

Comment 1 by rnimmagadda@chromium.org, Sep 22 2016

Cc: rnimmagadda@chromium.org
Labels: Needs-Feedback
@ekungurov83: Could you please provide us the screen-recording for the better understanding of this issue, which would help us in triaging it further.

Thank you.

Comment 2 by l446240525@gmail.com, Sep 22 2016 

$x("//body/..[1=1]")
Screen Shot 2016-09-22 at 6.45.43 PM.png
67.3 KB View Download
Screen Shot 2016-09-22 at 6.45.35 PM.png
29.0 KB View Download

Comment 3 by alph@chromium.org, Oct 10 2016

Components: -Platform>DevTools Blink>XML

Comment 4 by dominicc@chromium.org, Oct 14 2016

Labels: -Pri-2 Pri-3
Owner: dominicc@chromium.org
Status: Available (was: Unconfirmed)
I can reproduce this CrOS 54.0.2840.59 (Official Build) beta (64-bit).

We don't parse ..[1=1], if you pop open the console and do:

document.evaluate("//body/div/..[1=1]", document, null, XPathResult.ANY_TYPE, null).iterateNext()

we throw; for parent::* we don't. The problem probably lies in core/xml/XPathGrammar.y and the way the Step production uses AbbreviatedStep without any predicate.

This *does* appear to be per the XPath 1 spec: https://www.w3.org/TR/xpath/#section-Location-Steps

However XPath 2 accepts ..[1=1]:
https://www.w3.org/TR/xpath20/#id-steps

Note that Firefox accepts ..[1=1]. Matching other browsers should be the operative principle. Does ..[1=1] work in Edge? (I predict Safari behaves the same as Chrome but have not tried it.)

Comment 5 by dominicc@chromium.org, Oct 14 2016

Labels: OS-Android OS-Chrome OS-Linux OS-Mac

Comment 6 by phistuck@gmail.com, Mar 28 2017 

Edge 14 (BrowserStack) -
> document.evaluate("//body/div/..[1=1]", document, null, XPathResult.ANY_TYPE, null).iterateNext()
Syntax Error
XPATH15001: XPath query "//body/div/..[1=1]" not supported

Safari 10 (BrowserStack) -
> document.evaluate("//body/div/..[1=1]", document, null, XPathResult.ANY_TYPE, null).iterateNext()
INVALID_EXPRESSION_ERR (DOM XPath Exception 51): The expression had a syntax error or otherwise is not a legal expression according to the rules of the specific XPathEvaluator.


So only Firefox accepts it at the moment.

Comment 7 by dominicc@chromium.org, Mar 28 2017

Status: WontFix (was: Available)
Thanks Phistuck! They are useful data. Let me tentatively wontfix this.
►

Sign in to add a comment