Get Element(s) from Shadow root 'using' xpath and tagname property

[sarvaje]

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 the xpath 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

[jimevans]

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.

[AutomatedTester]

Unless I am misunderstanding, we should have support tag name as it is part of the DocumentOrShadowRoot mixin. If it's not working then we need to seek clarifications from DOM.

[sarvaje]

Not having these two selector strategies makes the "Find Element(s) From Shadow Root" inconsistent with the other "Find Element(s)"...

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. Also, even if the name is similar (“Find Elements”), the method you are using is not the same. Developers will be using different methods to get a shadow root or an element, so IMO, it is ok if those methods have different parameters.

[jimevans]

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.

[AutomatedTester]

Unless I am misunderstanding, we should have support tag name as it is part of the DocumentOrShadowRoot mixin. If it's not working then we need to seek clarifications from DOM.

@sarvaje @foolip can I get a response to my question? We seem to have removed something because of a misunderstanding of the DOM spec

[sarvaje]

The DocumentOrShadowRoot mixin is expected to be used by other standards that want to define APIs shared between documents and shadow roots.

@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 DocumentOrShadowRoot mixin should define APIs that both, Document and ShadowRoot, have in common, so if get an element by tag name is not supported (according to the spec) in ShadowRoot, it shouldn't be part of the mixin. But that is just my opinion supposing I'm reading the spec the right way.

[whimboo]

We should also discuss if drivers should return a unsupported operation error in case the search strategy is actually not supported.

[jimevans]

If a browser cannot support a location strategy, as disappointing as that is, I would support a remote end returning unsupported operation as a compromise.

[beliaev-maksim]

@whimboo yes I spawned the discussion in Selenium and we agreed that it is better to discuss in webdriver community. https://github.com/SeleniumHQ/selenium/pull/11893

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed "Unsupported Operation" for Get Element(s) from Shadow root 'using' xpath and tagname.

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/w3c/webdriver/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?

[gsnedders]

Some of this problem is the fact that XPath's DOM integration, especially regards to shadow roots, is relatively undefined.

Like, document.evaluate() has an arg (its second) which is Node contextNode. On the face of it, therefore, you should be able to pass a ShadowRoot.

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.