You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems we may have at some point broken the ability to get the text of an element.
I did a PR last year (#4230) to introduce shadow tree traversal when retrieving element text.
The general idea of this PR was to modify getElementText such that it will follow distributed children through slot and content elements, along with taking shadowRoot into account on each element.
However, having (painfully) stepped through the latest selenium source, it seems we now call getVisibleText instead.
This function appears to have knowledge of shadow dom, but presumably has a bug somewhere which im hitting (and trying to reproduce for you).
So:
can someone explain selenium-atoms vs atoms?
why do we have two apparently unrelated functions to retrieve element text?
we used to use getElementText in some way because older versions of selenium don't have the problem im seeing
The issue is that some shadow DOM children return empty text but do have text
Selenium is incredibly difficult to debug and often involves jumping through many hoops. So without spending another several hours trying to get my head around it, i cant really figure out where these "atoms" go and how they are used. if someone could give an overview somewhere, that would be very useful.
I had to pretty much attach to the chrome instance (devtools), break, then try to access the text of the element in my tests so my devtools catches the injected code. the injected code is obviously minified by this point and near unreadable. is there a better debug process/method for debugging the injected JS?
FYI, executing getElementText manually (through a very hacky execute call via webdriver) on the element results in the correct text.
It seems we may have at some point broken the ability to get the text of an element.
I did a PR last year (#4230) to introduce shadow tree traversal when retrieving element text.
The general idea of this PR was to modify getElementText such that it will follow distributed children through
slot
andcontent
elements, along with takingshadowRoot
into account on each element.However, having (painfully) stepped through the latest selenium source, it seems we now call getVisibleText instead.
This function appears to have knowledge of shadow dom, but presumably has a bug somewhere which im hitting (and trying to reproduce for you).
So:
selenium-atoms
vsatoms
?getElementText
in some way because older versions of selenium don't have the problem im seeingThe issue is that some shadow DOM children return empty text but do have text
Selenium is incredibly difficult to debug and often involves jumping through many hoops. So without spending another several hours trying to get my head around it, i cant really figure out where these "atoms" go and how they are used. if someone could give an overview somewhere, that would be very useful.
I had to pretty much attach to the chrome instance (devtools), break, then try to access the text of the element in my tests so my devtools catches the injected code. the injected code is obviously minified by this point and near unreadable. is there a better debug process/method for debugging the injected JS?
FYI, executing
getElementText
manually (through a very hacky execute call via webdriver) on the element results in the correct text.edit: i opened #5762 for this
The text was updated successfully, but these errors were encountered: