Proposal: Shadow DOM support in WebDriver

[andreastt]

Marc Fisher:

The current proposal for dealing with Web Components and their corresponding Shadow DOMs in WebDriver treats them similarly to frames; at any point in time the WebDriver session is operating within a particular DOM, either the top-level DOM or one of the Shadow DOMs of a particular Web Component. However, this makes interacting with pages that use Web Components extremely taxing, as the current DOM will have to be switched on a regular basis, and it is unclear over what time frame an element id found within a particular DOM will be considered valid. Instead I propose that the WebDriver wire protocol be extended with commands to get the list of attached Shadow DOMs for an elements as opaques IDs and to support new element and elements commands that are scoped to a particular DOM. Additionally, element IDs from Shadow DOMs be completely accessible as long they are the corresponding element attached to the Shadow DOM and the Shadow DOM is attached to the page.

For a more thorough description see:
https://docs.google.com/document/d/1qP7Se3MDUac5P0V1Kfm2yaj3fFhBOFCyWyXLcsVwkTA/edit?usp=sharing

[andreastt]

chrisgao:

Do we want to make it explicit in spec which commands are supported with Shadow DOM roots?
eg.: FindElement, FindElements, ExecuteScript, ExecuteAsyncScript, GetActiveElement and the like.

[andreastt]

Marc Fisher:

Of the current commands that take a WebElement:

findElement and findElements: Search scoped to the Shadow DOM.

execute[Async]Script: if a Shadow DOM root is passed as parameter it should be resolved to the correct ShadowRoot instance (http://www.w3.org/TR/shadow-dom/#shadow-root-object).

Any other command that takes an element id (e.g. isSelected, getElementAttribute, getText) should throw an exception if passed a Shadow DOM root. None of the current set of status codes seem appropriate, so maybe add a new one "operation not supported on shadow dom root".

It may be reasonable to add an optional element id parameter to the following commands:

getActiveElement: returns ShadowRoot.activeElement

getSource: returns ShadowRoot.innerHTML

If added, these commands should probably throw an exception if the element id doesn't correspond to a shadow dom root: "operation only supported on shadow dom root".

[andreastt]

chrisgao:

Update the patch for shadow dom according to the discussion in the F2F meeting at TPAC 2013.

Attachment: https://gist.github.com/andreastt/dcf4be00273f8ea55e37ef7c65d48881

[TakayoshiKochi]

Hi, I'm coming from w3c/webcomponents, and this issue seems relevant...

From a glance at the spec, the commands seem not at all aware of shadow roots or shadow trees:
https://w3c.github.io/webdriver/#list-of-endpoints

Is this still any of the interest from webdriver community?
This has been left for 1.5 years, but there are definitely interests from web testing community to access shadow trees, e.g. puppeteer/puppeteer#858 or https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ScMLN_Hj52E/discussion.

The main painpoint is that finding a specific element in the whole document including shadow trees, such as finding elements with class foo.

Is there anyone else who is interested in moving this forward?

[whimboo]

Please note that using execute (async) script and returning the shadow root of an element, it will also end-up in a cyclic object. So we need a definition similar to window, and element.

[AutomatedTester]

switch to shadow dom proposal in #1320

[aslushnikov]

The main painpoint is that finding a specific element in the whole document including shadow trees, such as finding elements with class foo.

@TakayoshiKochi we think we found a nice approach to deal with Shadow DOM in Puppeteer: "JS Path". It's pretty light-weight and had a very positive initial feedback from our clients.

[AutomatedTester]

@aslushnikov That appears to only work for open Shadow DOM. With WebDriver we could just evaluate script and work with the returned element and it would work the same as it does in puppeteer.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Shadow DOM.

The full IRC log of that discussion

<AutomatedTester> Topic: Shadow DOM
<AutomatedTester> Github Topic: https://github.com//issues/350
<AutomatedTester> jimevans: With the rising use of web components the ability to interact with Shadow DOM is getting more important
<AutomatedTester> ... right now those components are opaque to webdriver
<AutomatedTester> ... there are some work arounds using executeScript
<AutomatedTester> ... and some XPATH libraries have been able to pierce Shadow DOM because CSS does not have the ability to pierce the shadowroot
<jgraham> q+
<AutomatedTester> ... we need a way to "switch" or "select" into a shadow dom and test the elements in there
<AutomatedTester> ... I have a straw man proposals
<AutomatedTester> ... THere are some outstanding questions:
<AutomatedTester> ... 1) What do we do with closed roots
<AutomatedTester> ... 2) and how do we handle this. E.g. could we do element.getShadowRoot() and continue from there
<jimevans> https://docs.google.com/document/d/15DYXZyWsahr1peyOWmi2QGgzi3Xb2GlITyywx-2cPXc/edit?usp=sharing
<cb> https://github.com//pull/1320/files
<AutomatedTester> q?
<AutomatedTester> ack jgraham
<AutomatedTester> jgraham: I like the shape of the proposal
<AutomatedTester> ... and like going element and being able to pierce this makes sense
<foolip> q+
<AutomatedTester> ... and I think that the reason why this hasn't happened hasnt been fundamental opposition to this, purely time
<jgraham> q+
<AutomatedTester> AutomatedTester: I remember from TPAC last year that the DOM member from Apple said there was opposition to allowing Shadow Roots from being pierced and they said this is the main reason why CSS piercing was not allowed but Jim has told us that XPATH can get around this issue
<AutomatedTester> q?
<AutomatedTester> ack foolip
<AutomatedTester> foolip: if I remember on Monday jgraham said that Shadow Roots would not be interacted the same was as in bidi as http
<AutomatedTester> ack jgraham
<AutomatedTester> jgraham: in answer to foolip the serialisation is more generic
<AutomatedTester> ... we would serialise it and it would just serialise that is has a shadowroot
<AutomatedTester> ... since we have generic concept of node and not a web element
<foolip> ok that makes sense, if we're talking about merely finding out that something is a shadow host
<AutomatedTester> jgraham: It feels like the DOM are not understanding us here and perhaps we need to go speak to them
<foolip> q?
<AutomatedTester> ... since this is open to Devtools but not us
<AutomatedTester> ... and the next item is to I wonder if we can simplify the API to accept a now and reusing webelement.
<foolip> q+
<AutomatedTester> q+
<AutomatedTester> ack foolip
<jgraham> q+
<AutomatedTester> foolip: Is the frustration that people can not pierce things or are we going to have to do it for every boundary
<AutomatedTester> jimevans: the proposal is to minimize the cognitive load to keep it "similar" to find elements
<AutomatedTester> ... except the sematics would be that you are specifically looking in the shadow
<AutomatedTester> ... no thoughts have been given for chaining
<cb> q+
<AutomatedTester> ... this is purely for http and agree that bidi should be different
<AutomatedTester> ack AutomatedTester
<drousso> q+
<AutomatedTester> AutomatedTester: I can't see the how the people trying to reuse findElement as they seem very different to me, could you elaborate it
<mathiasbynens> q+
<AutomatedTester> jgraham: I think that the DOM hierarchy would be on our side so we will be fine
<AutomatedTester> ack jgraham
<AutomatedTester> jgraham: ffor foolip: re: CSS piercing was seen as bad by other WG
<AutomatedTester> ... and for piercing we need to make sure that piercing the Shadow DOM needs to be explicit
<AutomatedTester> ... I think we should do the simple case first and see how it goes
<AutomatedTester> q?
<AutomatedTester> ack cb
<jgraham> RRSAgent: make minutes v2
<RRSAgent> I have made the request to generate https://www.w3.org/2020/10/28-webdriver-minutes.html jgraham
<AutomatedTester> cb: I have a counter proposal. It would be good to extend element.findElement(withShadow=true) and that would look inside the shadow
<AutomatedTester> q?
<jgraham> q+
<AutomatedTester> jimevans: I don't have a problem with that approach either
<AutomatedTester> ... we just need to something
<AutomatedTester> ... the tricky bit we need to think about is that we have a new error code
<AutomatedTester> ... if you want inside a shadowRoot and we cant find it its because of the shadow dom and not the DOM
<AutomatedTester> q?
<AutomatedTester> ack drousso
<AutomatedTester> drousso: regarding piercing, I dont think that we want "special paths" for automation
<AutomatedTester> ... or these special paths need to be infrequent
<AutomatedTester> q?
<AutomatedTester> ack mathiasbynens
<AutomatedTester> mathiasbynens: in puppeteer we allow people to allow people register querySelectors on their own
<AutomatedTester> ... and then people can do what they want from there
<AutomatedTester> ... we have one called `pierce` that pierces shadowROot
<AutomatedTester> and one called `aria` for accessibility
<AutomatedTester> ... I think that playright does something similar
<AutomatedTester> q?
<AutomatedTester> ack jgraham
<AutomatedTester> jgraham: so looking at the PR we had this discussion 2 years ago
<AutomatedTester> ... the backwards compatiblity issue is that if we add new parameters then we can have silent failures
<mathiasbynens> To clarify, in Puppeteer you opt-in to shadow DOM piercing not through some new parameter, but by adding a prefix to the selector string. This was decided because that way, we can make it work for our 10+ APIs that accept selector strings
<AutomatedTester> ... the new end points mean you will get an explicit error here
<AutomatedTester> ... and that is better for everyone
<mathiasbynens> Puppeteer's built-in pierce handler: https://github.com/puppeteer/puppeteer/pull/6509/files
<AutomatedTester> Resolution: Write up spec prose based on jimevans proposal and the for future proposals in this area use the learning from other frameworks to see how we can improve

[jgraham]

I think we can close this issue now we have basic shadow dom support. Any additional feature requests should go in new issues.