Closed Bug 963933 Opened 10 years ago Closed 4 years ago
Search for elements by XPath selectors
47 bytes, text/x-phabricator-request
|Details | Review|
47 bytes, text/x-phabricator-request
|Details | Review|
8.27 KB, image/png
Severity: normal → enhancement
Component: Untriaged → Developer Tools: Inspector
OS: Windows 7 → All
Hardware: x86_64 → All
It's already possible to search via CSS selectors in the Inspector, as that's what is accepted by the search field there. Renaming this bug to be about XPath only, since CSS selector search already exists.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Inspect elements by CSS and XPath selectors → Search for elements by XPath selectors
Sorry, I did not see that CSS selector search is already implemented. I just have checked it, and it actually works very well.
(In reply to Géza Búza from comment #2) > Sorry, I did not see that CSS selector search is already implemented. I just > have checked it, and it actually works very well. Do you think XPath is also needed, or does selector search seem sufficient? My guess is that the number of web developers that know XPath well is much smaller than those that know CSS selectors.
Chrome is in the process of removing XSLT . I suspect that XSLT is the largest  feature of browsers that has ever been actually removed. Sure, XSLT != XPath, but they're from the same family, and I'm not sure we need to add XPath features now. : https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zIg2KC7PyH0[101-125-false] : In terms of lines of code
@Ryan, @Joe I understand your concerns and basically agree with you. But I am going to describe why it could be useful for me. As a web developer when I have to write automated tests I often need to check the existance of a content in the current page. Let's say I need to look for a SPAN element with content in it. Here I can use an XPath like this: //span[text()='some content'] The same check with CSS selectors would involve more coding, because first I search for all SPAN, then read the text content from code one by one and check if one of the is equals to "some content". To sum up, I think Xpath is not a must have feature, but sometimes it could come handy.
(In reply to Géza Búza from comment #5) > To sum up, I think Xpath is not a must have feature, but sometimes it could > come handy. Selenium, right? I guess we *could* have devtools try an XPath match if querySelector failed, which would be low UI impact. But I'm still concerned that this is a deprecated feature. If FF follows Chrome in removing XSLT, and XPath comes next then we'd need to remove this feature.
That's right, I use Selenium. As far as I know XPath does not depend on XSLT, but XML document and XML Schema, so you can safely remove XSLT. And it is not so old piece of technology, because if you take a look at http://www.w3.org/TR/xpath20/ you can see that the second version was approved in 2010. Maybe some kind of usage statistic could help to decide. Anyway, do what you think is the best! :)
fwiw, we have the $x() helper which returns an array of matching nodes in the Console.
Thanks @Rob. That's fair enough.
No feedback on this for a while, and we don't have in our current plan to add support for XPATH now.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Patrick, I got several requests lately related to FirePath not working anymore. Most of them are related to bug 987877, but some of them are related to this one. Joe's point that XPaths are a deprecated feature might become valid in the future, though the latest spec. is newer than his post and the thread related to Google's intent to deprecate XSLT contains comments indicating that there is no intent to deprecate XPath. Therefore, I reopen this issue. Sebastian  http://stackoverflow.com/q/41992056/432681  https://groups.google.com/d/msg/firebug/Q6eyvGt6hyI/yFFO5ji-CAAJ  https://www.w3.org/TR/xpath-30/  https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zIg2KC7PyH0%5B1-25%5D
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Thanks Sebastian. These are good points. It is also a Firebug and Chrome gap. Let's triage this as a P2 enhancement.
Priority: -- → P2
There is also the case of XPath being the only method to walk the DOM up and down. There are many circumstances especially when testing that there is no ID or easy CSS way to get to the object. So, you have to do an XPath search for Value= or Text=, walk up the DOM, then back down to get to the object you want. I find XPath to be critical, and FirePath is my number one used add-in.
We need both (Xpath and Css). And i agree : The best tool with firebug is "FirePath", easy to use and work the both type. We need the same thing in Dev ToolBar. "There is also the case of XPath being the only method to walk the DOM up and down." : (for me) Xpath is harder to understand and the selector provided is not always the most accurate. I use in this case a tool provided by the quasi defunct Autopager addon (https://addons.mozilla.org/en-US/firefox/addon/autopager/). Its built in function to create a XPath by click some links on the pages is very intuitive and useful. If it is possible it should be a great improvement to include something similar to the Dev Toolbar.
I write automated tests (Selenium, Protractor, TestComplete) using a mix of CSS and XPath and all of the points mentioned above regarding XPath support make good sense to me: 1. //*[text()='<contentText>'] and //*[@class='<className>'] covers almost all of the elements I normally need 2. I use "FirePath" for quickly verifying the Xpaths before adding them to tests. It has been a life saver on more occasions than one and I would really want it back. 3. "There is also the case of XPath being the only method to walk the DOM up and down" - without this ability, some of the scenarios I have had to automate would have become very complicated.
I've been doing automated software testing for over 20 years now and although CSS is very helpful it tends to be more helpful for developers. Although a lot of my testing has shifted to API testing which does not require the GUI or any CSS or XPATH, for testing the headfull layer XPATH can be critical as testers do not always have access to the information they need to determine what element(s) to use and being able to traverse the DOM and type in an XPATH and see all the elements that it hits can save a lot of time and provides for a very large ROI.
Another automation engineer here. One of the nice features of firepath/bug was that you could search for elements via Xpath to ensure that your locators were identifying a unique match on the page...automation runs into issues when locators are not unique.
also posting my request for xpath locator. I used it all the time with Firepath, and would like to see it implemented here in the developer tools.
Just a hint for everyone asking for this feature in regard of automated testing: Selenium (and I'm sure other tools, too) also supports CSS selectors to select elements, which should be sufficient in most cases. There are a few cases where you still need XPaths, though, like selecting elements by their text contents (e.g. //*[text()='Text content']). Sebastian
Thanks for your comments so far folks. We'll prioritize this enhancement request. Note that the $x() function in the console can locate elements based on an xpath argument. It's not as nice as being able to run the xpath inside the search field of the inspector, but it's better than nothing. Example: $x("//html/body")
@Aditya and everyone interested in this feature, please read comment 23 and comment 20 for workarounds. Also, another workaround is to copy the XPath of an element via the context menu. Furthermore, there are currently two add-ons allowing to search elements by XPath. (The latter doesn't seem to work for me, though.) Having said that, if you want to express your advocacy for this feature, please vote for it using the Vote button at the top instead of commenting. Please *only* comment if you want to provide information to help with the implementation. See https://bugzilla.mozilla.org/page.cgi?id=etiquette.html point 4 under "Commenting". Otherwise it's just noise for the others following this bug. Sebastian  https://addons.mozilla.org/firefox/addon/xpath_finder/  https://addons.mozilla.org/firefox/addon/try-xpath/
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/ed3f61f1c32c Allowed searching for elements via XPath in Inspector. r=jdescottes https://hg.mozilla.org/integration/autoland/rev/d33b655d9fab Tests for searching for elements via XPath in Inspector. r=jdescottes
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/b3e868335a61 Allowed searching for elements via XPath in Inspector. r=jdescottes https://hg.mozilla.org/integration/autoland/rev/89218ad04c6d Tests for searching for elements via XPath in Inspector. r=jdescottes
Flags: needinfo?(wbamberg) → needinfo?(jswisher)
You need to log in before you can comment on or make changes to this bug.