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.
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.
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
Thanks Sebastian. These are good points. It is also a Firebug and Chrome gap. Let's triage this as a P2 enhancement.
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.