Search for elements by XPath selectors



5 years ago
14 days ago


(Reporter: bghome, Unassigned)


(Blocks: 2 bugs)

26 Branch
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131205075310

Steps to reproduce:

As a developer I want to find elements by typing a CSS or XPath expression. It could came handy when debugging or when testing.
I would like to see support in DevTools for it.

Actual results:

Currently I can achieve this using JavaScript eg. jQuery.

Expected results:

I expect to have an input text filed for the CSS / XPath expression and a results list for the matched elements.


5 years ago
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.
Ever confirmed: true
Summary: Inspect elements by CSS and XPath selectors → Search for elements by XPath selectors

Comment 2

5 years ago
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 [1]. I suspect that XSLT is the largest [2] 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.

[2]: In terms of lines of code

Comment 5

5 years ago
@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.

Comment 7

5 years ago
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 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.

Comment 9

5 years ago
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.
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
Blocks: 991806
Patrick, I got several requests lately related to FirePath not working anymore. Most of them are related to bug 987877, but some of them[1][2] are related to this one.

Joe's point that XPaths are a deprecated feature might become valid in the future, though the latest spec.[3] is newer than his post and the thread related to Google's intent to deprecate XSLT[4] contains comments indicating that there is no intent to deprecate XPath.

Therefore, I reopen this issue.


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

Comment 13

2 years ago
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.
Comment hidden (me-too)
Blocks: 1267303

Comment 15

2 years ago
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 (
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.

Comment 16

a year ago
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.

Comment 18

a year ago
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.

Comment 19

a year ago
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']).

Comment hidden (advocacy)
Comment hidden (advocacy)
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")

Comment 24

a year ago
Hi All,

Sorry commenting on same thread on which it is already discussed. I am totally new to selenium and we have been using firefox 52 with firebug and firepath, but with new releases of firebug (ver 2.0.19) firepath is not compatible. I tried to downgrade but firebug 1.8 is not compatible with firefox 54, I am in a soup, I am having trouble in creating codes, I tried upgradingto firefox 56, but xpath and firebug both are not compatible, Can you please provide a workaround to fetch Xpath, meanwhile you work on a way to fix the issue, Please!!!!!!!!!!!!
@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.[1][2] (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 point 4 under "Commenting". Otherwise it's just noise for the others following this bug.


Comment hidden (advocacy)


9 months ago
Product: Firefox → DevTools

Comment 27

29 days ago

Searching for elements by XPath via the Inspector's find tool was a great alternative, but now it is also gone.

Duplicate of this bug: 1531090
Duplicate of this bug: 1531733
You need to log in before you can comment on or make changes to this bug.