Shadow DOM traversal support

[43081j]

I've been gradually trying to push support of shadow DOM v1 into selenium (see #4230, #5762).

However, we are still missing one major piece: traversal.

There needs to be some ability to traverse shadow DOM when calling FindElement and what not.

So maybe we can discuss some possible implementations here?

What we can't/shouldn't do:

• Alter how existing selectors work (CSS, XPath, etc. they should all behave as they do now)
• Implement deprecated things like /deep/
• Implement our own selector syntax/mechanism

The way I see this working is that we should treat the DOM as we would in the browser, meaning there will not be a way to select a deep element in one call:

element
  .FindElement(By.CssSelector("foo"))
  .ShadowRoot?
  .FindElement(By.CssSelector("bar"));

Which, in the browser, would be structured the same (no shortcuts):

element
  .querySelector('foo')
  .shadowRoot
  .querySelector('bar');

So maybe we just need to implement ShadowRoot on WebElement? Which can be null (just like in the browser).

[p0deje]

cc @jleyba @juangj @barancev @shs96c

[43081j]

also, while i do disagree with us implementing some kind of "shortcut", something like this could work:

element
  .FindElement(
    By.ShadowSelector(
      By.CssSelector("foo"),
      By.CssSelector("bar")
    )
  );

which is the equivalent of element.querySelector('foo').shadowRoot.querySelector('bar').

i can imagine there are plenty of people who want a "lazy" way to do whats in my original post, without the need for null checking and what not. Basically a single FindElement call to achieve the same as the expanded form.

either way i think we still need to implement ShadowRoot though at least.

[p0deje]

Even though I don't fully follow the request, I see nothing in regards to shadow root in specification. To my knowledge, support for custom commands like ShadowRoot is required to be implemented in underlying drivers and so has to be a part of specification.

[43081j]

The request is to provide shadow DOM support. To provide a way of using FindElement to reach nodes contained within shadow DOM trees.

Currently, you do not have any support for shadow DOM at all in regards to traversing the tree.

So if we can't add ShadowRoot, what do you suggest?

[AutomatedTester]

Originally we had been discussing this mostly in the same approach as frames so you would do.

shadow_root = driver.find_element(...)
driver.switch_to_shadow_root(shadow_root)
driver.find_element(....).click()

This is how I have recently been implementing in Firefox as Firefox's shadow DOM becomes live.

Then if you wanted to traverse back up the tree you would do

shadow_root = driver.find_element(...)
driver.switch_to_shadow_root(shadow_root)
driver.find_element(....).click()
# Traverse back to the main tree
driver.switch_to_shadow_root(None)

[43081j]

A solution like that makes sense to me too, its a very similar way of tackling it to my original idea (ShadowRoot property).

Though I do think there should be a way of accessing a root relative to an element...

Just like you can do Element.FindElement or Driver.FindElement.

You don't always have the original driver instance which created the element you are being passed, so how do you reach a shadow root from only a WebElement?

Of course there are ways around that (refactor so you do have a ref to the driver), but it seems to me it would be quite nice to have access through the element, being that is what "owns" it.

Right now many people have to resort to executing a script which returns arguments[0].shadowRoot essentially.

[jimevans]

@43081j I’ll just point out that in Java st least (and .NET), you do almost always have a reference to the parent driver. You can usually cast to WrapsDriver and use getWrappedDriver() (or something similar; I may have the syntax slightly wrong there).

[43081j]

@jimevans really didn't realise there was a reference to the driver there 🙈

in that case, its fair enough, having a switch_to_shadow_root makes a lot of sense.

though do remember, find_element right now can't get a direct ref to the shadow root. so are you saying switch_to_shadow_root takes the element as a parameter? (not the shadow root its self)

[AutomatedTester]

@43081j shadow root is a property of an element so passing in the element and then looking for the property makes sense to pass in the webelement.

The think that gets tricky is when we hit the issue of the closed shadow DOM vs what we do with an open shadow DOM.

[43081j]

yup sounds good to me.

as for closed shadow roots, i think it should just be accepted that you can't access it (throw an exception).

reason being, shadowRoot in the DOM its self will be null. so that way our method is following the same behaviour. as far as i know, there's no way to access it without a reference from the initial attachShadow call, which we will/can never have really...

so if we call switch_to_shadow_root and shadowRoot is null, throw an exception? because that covers both closed roots and non-existent roots.

[AutomatedTester]

Yes, we need to throw an exception when shadowRoot is null, I am currently throwing NoSuchElement though I am not married to that solution. I am happy to see about adding a new exception type if need people want that

[43081j]

a new exception would make more sense i think, seeing as its not an element really. its a document fragment i guess.

so either an exception specific to shadow roots, or one a little more generic tied to documents (NoSuchDocument, NoSuchFragment, NoSuchShadowRoot, etc but better worded).

i dont think we need to care about closed roots as we shouldn't be able to access them anyway. which makes the logic as simple as "is it null or not".

[p0deje]

If I understand correctly, we need to make it a part of spec (like frame switching), don't we? Or can we implement it purely in client bindings?