-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get Element(s) from Shadow root 'using' xpath and tagname property #1610
Comments
IIRC, there are some cases where using XPath outside of a shadow root will pierce into a shadow root to access elements (that's IIRC, and I may not be "recalling correctly"). This seems to indicate that it's possible to use XPath for a shadow root, at least in some cases. Not having these two selector strategies makes the "Find Element(s) From Shadow Root" inconsistent with the other "Find Element(s)" commands, and that inconsistency should be avoided. Just because something can't be done via JavaScript doesn't mean it should be disallowed via WebDriver. It may not be easy for an implementer, but users shouldn't be penalized for that difficulty. I guarantee that supporting some but not all locator strategies will be a source of issue reports for implementers, even if we modify the spec to disallow the more challenging ones. |
Unless I am misunderstanding, we should have support tag name as it is part of the |
I don't agree 100%, IMO it would be inconsistent if they were the same, but an Element and a shadow root are not the same thing. |
A shadow root may not be the same as an element, but it most certainly is analogous* to a document, from which one can also find an element. I stand by my analysis that not having this parity will be an unending source of bug reports from users who will not appreciate the inconsistency. This applies both to client implementations like Selenium, and to browser maintainers who will eventually get the upstream issue reports. *”Analogous,” not identical, in case others are feeling pedantic. |
@sarvaje @foolip can I get a response to my question? We seem to have removed something because of a misunderstanding of the DOM spec |
@AutomatedTester I'm not an expert reading specs (neither English is my native tongue so can be misreading it), but for what I'm understand in the previous quote, the |
We should also discuss if drivers should return a |
If a browser cannot support a location strategy, as disappointing as that is, I would support a remote end returning |
@whimboo yes |
The Browser Testing and Tools Working Group just discussed The full IRC log of that discussion<jgraham_> Topic: "Unsupported Operation" for Get Element(s) from Shadow root 'using' xpath and tagname<jgraham_> GitHub: https://github.com//issues/1610 <jgraham_> whimboo: Firefox now supports finding elements from a shadow root. We have different locator stratgies. Currently it doesn't work to use xpath or tagname from a shadow root. Should we have a specific error? Currently we emit unknown error <jgraham_> jgraham: Because the spec doesn't consider the possibility of the locator strategy not working? <jgraham_> whimboo: Yes <jgraham_> q? <jfernandez> mathiasbynens (IRC): done <JimEvans> q+ <jgraham_> jgraham: This is because the APIs the spec assumes exist aren't on shadowroot <jgraham_> gsnedders: They also don't exist on document fragement. <jgraham_> ack JimEvans <JimEvans> In the ideal world, all locator strategies would work in all find cases. We are not in an ideal world. It’s a cause of confusion that they don’t work. <JimEvans> A specific error would be better than not. <JimEvans> Or more appropriate than “unknown error” <jgraham_> gsnedders: TagName seems like it should work. That doesn't have much complexity so it's not surprising. XPath is harder, and DOM people might have opinions on whether that's reasonable. <whimboo> q+ <jgraham_> jgraham: I propose that we redefine the tag name locator strategy to not depend on getElement(s)ByTagName so it can work on shadow roots. I also propose that in general we allow the find elements commands to fail if the strategy isn't supported for some reason <jgraham_> ack whimboo <jgraham_> whimboo: We have "invalid selector", can we use that? <jgraham_> jgraham: I assume that's more for invalid css selectors. The obvious one would be "invalid argument" but that's very non-specific <jgraham_> q? |
Some of this problem is the fact that XPath's DOM integration, especially regards to shadow roots, is relatively undefined. Like, It might be worth filing a bug on the DOM spec if this doesn't work, or at least write some tentative tests that shows the current behaviour of browsers. |
According to the documentation:
https://w3c.github.io/webdriver/#find-element-from-shadow-root step 2
https://w3c.github.io/webdriver/#find-elements-from-shadow-root step 2
the value for using has to be one of the Locator strategies table.
But for what I can see in https://dom.spec.whatwg.org/ there no method to get elements from a tag name in a shadow root.
Experimenting in Chromium and Firefox I can neither use
xpath
in a shadow root. For thexpath
I'm not sure if is because is not defined in the standard or because they don't have it implemented, but right now is not supported.For more context you can take a look to this thread in the WPT repository
The text was updated successfully, but these errors were encountered: