[🚀 Feature]: Python Difficulties with ShadowRoot object interface

Feature and motivation

The ShadowRoot object interface differs from the WebElement object interface in terms of keyword arguments on some similar functions:

Currently the ShadowRoot object find_element and find_elements functions have the signature: def find_element(self, using, value):

def find_elements(self, using, value):

however the webelement objects have:

def find_element(self, by=By.ID, value=None):

def find_elements(self, by=By.ID, value=None):

The issue with this is that it prevents using the shadow root elements and the web elements when duck typing as if you try and use something like:

element.find_element(by=By.NAME, value='test-element')

this won’t work when the element happens to be a shadow root as the keyword arguments don’t line up (forcing you to not use keyword arguments).

Another issue i’ve run into when migrating to selenium 4 is that the ShadowRoot class is hidden from the interface, which i think is because in the Java and .net versions of the package the aim is to use the SearchContext, however this isn’t available in the python package and so it feels a bit difficult to use as a result e.g.

• theres no option to overwrite the internal functions with adjusted ones.
• The exception NoSuchShadowRootException doesn’t seem to be public on the exceptions module
• When you get a detached shadow root it seems to get wrapped into a NoSuchElementException whereas it would be nice if we could react to the shadow root becoming detached (similarly to a stale element exception) rather than it looking like the element doesn’t exist.

Usage example

Aligning the interfaces between shadow roots and webelements would mean we could treat them similarly when a function might return either a shadow root or a web element and then whatever it returns we want to then search inside that element for another element, currently you need to treat them differently or not use keyword arguments.

If the ShadowRoot object was made public we would be able to monkeypatch functions within it, this can be useful for example we have a complicated dom structure where we want to search through elements and their shadow roots without needing to be too specific, e.g. find_element(By.NAME, ‘publish-button’) - This publish-button is unique on the page but we don’t want to specify exactly which shadow root / element it is inside, in the past we have overwritten the find_element function to ignore certain shadow roots as they contain a lot of nested elements, which would take a long time.

Being able to import the NoSuchShadowRootException without getting warnings from your IDE would be a QOL change.

Being able to distinguish between a shadowroot becoming detached and the element not existing at all would be useful in error handling / retries.

[titusfortner]

We need to get the rst files figured out as part of this as well.

[titusfortner]

Updating the method to use keywords seems straightforward. #10138

I can verify that PyCharm complains about importing the exception, even though it is able to find it when run. I’m going to guess that it decides what to complain about based on what is in the *.rst files. @AutomatedTester the NoSuchShadowRootException is not showing up in the autosummary section in selenium.common.exceptions.rst. Same thing with shadowroot.py not having an *.rst file. How does one generate these files?