The getText atom

111 views
Skip to first unread message

Simon Stewart

unread,
Jan 12, 2017, 7:46:33 AM1/12/17
to selenium-developers
Hi folks,

The W3C webdriver spec has decided to use the implementation of "getText" from selenium webdriver as the basis of the "get text" command. In order to do this, we need to take a snapshot of the existing atom and add it as an appendix to the spec.

Since adding to the spec will effectively freeze it, now's our last chance to either state that we're okay with the current implementation, or find and fix any outstanding issues with it that we can both find and fix. We should also clearly state the edge cases where we know this algorithm won't work.

So, from the selenium developers: are we okay with this atom freezing?

Simon

Paul Hammant

unread,
Jan 12, 2017, 8:03:43 AM1/12/17
to selenium-developers
When we getText on a node that has child nodes, there a no way of specify the delimiters that make it to the resulting string.

It would be cool if that were added (with a default of empty string), and that'd be down in the atom - right?

- Paul

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYEH09r5QU5axY20Bhd%2BHSDpqzjLJrR%2BQbc96E-tUQfXuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Mark Charsley

unread,
Jan 13, 2017, 4:51:52 AM1/13/17
to Selenium Developers
There is an issue with Shadow DOM IIRC. The text grabbed is form the logical DOM, not the displayed DOM, so what's displayed in your browser and what's returned by getText can be wildly different.

Chromedriver has a second atom that gets the text from the displayed DOM whose results match what the user sees a lot better. I intended to add some sort of extension/capacity thing to allow clients to choose which atom they wanted, but never got around to it. There are a few tests I'm aware of that run the atom via JavascriptExecutor however.

I'll leave it to wiser heads than mine to decide whether Shadow DOM is important enough to care about...

Mark

Simon Stewart

unread,
Jan 13, 2017, 7:47:03 AM1/13/17
to selenium-...@googlegroups.com
Is that shadow dom aware atom something we should roll into the main tree? I suspect that the shadow dom is something we should care about. 

Can I ask why you'd need a flag? Why not always use the one that understands the shadow dom?

Simon "types shadow dom a lot, it seems" Stewart

Sent from my iPhone
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com.

Mark Charsley

unread,
Jan 13, 2017, 9:03:48 AM1/13/17
to Selenium Developers
Without wanting to point any fingers, when I was working on this a colleague of mine, a certain Mr. Rowe did ask "a senior member of the selenium team" :-) about this and relayed back to me that the standard didn't cover Shadow DOM, and thus we shouldn't change the behaviour.


To give an idea of the difference, if you look at the attached html, then the default gettext gives
Page for Shadow DOM chromedriver testsThe page has a shadow root that in turn contains two shadow roots. So we can check behaviour with both nested roots and younger/older sibling roots. The various sections are highlighted with colored borders to make it more obvious where each element comes from.Base-level Stuff
Whereas the shadow-dom aware version gives
Page for Shadow DOM chromedriver tests
The page has a shadow root that in turn contains two shadow roots. So we can check behaviour with both nested roots and younger/older sibling roots. The various sections are highlighted with colored borders to make it more obvious where each element comes from.Younger Child
Younger Child Contents
Stuff for for the younger child.
Younger Child Shadow
Older Child
As the older child of a nested shadow root, this is the most likely to go wrong bit of the page.Older Child Contents
Parent
Parent Contents
Base-level Stuff

I've since moved on to other things, so I haven't kept up with how accepted Shadow DOM is these days, but if you are going to freeze/standardize behaviour, it's probably best to take a look at this first...

Mark

On Friday, January 13, 2017 at 12:47:03 PM UTC, Simon Stewart wrote:
Is that shadow dom aware atom something we should roll into the main tree? I suspect that the shadow dom is something we should care about. 

Can I ask why you'd need a flag? Why not always use the one that understands the shadow dom?

Simon "types shadow dom a lot, it seems" Stewart

Sent from my iPhone

On 13 Jan 2017, at 12:51, 'Mark Charsley' via Selenium Developers <selenium-...@googlegroups.com> wrote:

There is an issue with Shadow DOM IIRC. The text grabbed is form the logical DOM, not the displayed DOM, so what's displayed in your browser and what's returned by getText can be wildly different.

Chromedriver has a second atom that gets the text from the displayed DOM whose results match what the user sees a lot better. I intended to add some sort of extension/capacity thing to allow clients to choose which atom they wanted, but never got around to it. There are a few tests I'm aware of that run the atom via JavascriptExecutor however.

I'll leave it to wiser heads than mine to decide whether Shadow DOM is important enough to care about...

Mark

On Thursday, January 12, 2017 at 12:46:33 PM UTC, Simon Stewart wrote:
Hi folks,

The W3C webdriver spec has decided to use the implementation of "getText" from selenium webdriver as the basis of the "get text" command. In order to do this, we need to take a snapshot of the existing atom and add it as an appendix to the spec.

Since adding to the spec will effectively freeze it, now's our last chance to either state that we're okay with the current implementation, or find and fix any outstanding issues with it that we can both find and fix. We should also clearly state the edge cases where we know this algorithm won't work.

So, from the selenium developers: are we okay with this atom freezing?

Simon

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
shadow_dom_test.html

Simon Stewart

unread,
Jan 14, 2017, 5:06:07 AM1/14/17
to selenium-developers
I suspect that senior member of the team was me :) At the time, Shadow DOM wasn't guaranteed to become a spec. It now looks like it's being absorbed into a variety of different places, and is a Real Thing. *sigh* I suspect it'd be better to use the more extensive getTextInComposedDom as the basis for the webdriver spec. And to flip the implementation in selenium.

Simon

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsubscribe...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com.

Mark Charsley

unread,
Jan 16, 2017, 5:30:56 AM1/16/17
to Selenium Developers


On Saturday, January 14, 2017 at 10:06:07 AM UTC, Simon Stewart wrote:
I suspect that senior member of the team was me :)

Well I didn't want to point any fingers, but yes it was :-)

At the time, Shadow DOM wasn't guaranteed to become a spec. It now looks like it's being absorbed into a variety of different places, and is a Real Thing. *sigh* I suspect it'd be better to use the more extensive getTextInComposedDom as the basis for the webdriver spec. And to flip the implementation in selenium.


My ShadowDOM stuff was only tested on chrome, but - other than obviously requiring ShadowDOM support in the first place - I don't recall using any particularly chrome-only features. So hopefully it should be fairly trivial to port to other platforms.

Mark


 
Simon

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Simon Stewart

unread,
Jan 16, 2017, 9:36:39 AM1/16/17
to selenium-developers
On Mon, Jan 16, 2017 at 10:30 AM, 'Mark Charsley' via Selenium Developers <selenium-...@googlegroups.com> wrote:


On Saturday, January 14, 2017 at 10:06:07 AM UTC, Simon Stewart wrote:
I suspect that senior member of the team was me :)

Well I didn't want to point any fingers, but yes it was :-)

Hahaha. :)
 
At the time, Shadow DOM wasn't guaranteed to become a spec. It now looks like it's being absorbed into a variety of different places, and is a Real Thing. *sigh* I suspect it'd be better to use the more extensive getTextInComposedDom as the basis for the webdriver spec. And to flip the implementation in selenium.


My ShadowDOM stuff was only tested on chrome, but - other than obviously requiring ShadowDOM support in the first place - I don't recall using any particularly chrome-only features. So hopefully it should be fairly trivial to port to other platforms.

It's things like this that make we wary. Are the APIs being used stable? Will they make it to REC? Does anyone else implement them? Once it's in the spec we don't get a chance to port to other platforms….

Cheers,

Simon
 
Mark


 
Simon

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsubscribe...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsubscribe...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

Mark Charsley

unread,
Jan 17, 2017, 3:36:18 AM1/17/17
to Selenium Developers
I've got no skin in the game (other than bragging rights being able to point to a bit of standard and say "I helped with that"): my current project doesn't use shadow DOM. But load up that html file I attached earlier in a shadow DOM enabled browser (e.g. chrome, firefox after you've set dom.webcomponents.enabled) and - after you've wiped away the tears caused by it's inexpressible, sublime beauty - ask yourself what you'd expect gettext to return.

If the W3C spec has made shadow DOM part of the spec, then I'd argue they need to make getTextInComposedDom the specified behaviour. If shadow DOM is deprecated then ignore getTextInComposedDom completely. If shadow DOM is still in draft proposal mode, then tell the appropriate folks that they should extend the draft proposal to cover changing the behaviour of gettext to match getTextInComposedDom.

Mark
Mark


 
Simon

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

Simon Stewart

unread,
Jan 17, 2017, 6:51:21 AM1/17/17
to selenium-developers
David pointed me at the platform status page from Mozilla, which shows us that the APIs are already fairly widely adopted. According to the W3C the spec is stable. I'll make the switch in the atoms and we'll see what happens.

Cheers,

Simon

Mark


 
Simon

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsubscribe...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsubscribe...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsubscribe...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/44ab2b4e-85c6-4508-9489-ee99b2e2a212%40googlegroups.com.

Mark Charsley

unread,
Jan 18, 2017, 6:21:19 AM1/18/17
to Selenium Developers
Cool. Mail me directly if you have any issues, and I'll desperately try to trawl my memories and email archives to see what I was thinking at the time.

Mark
Mark


 
Simon

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages