The getText atom

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

The getText atom

Simon Stewart
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: The getText atom

Paul Hammant-3
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

On Thu, Jan 12, 2017 at 7:46 AM, Simon Stewart <[hidden email]> 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 [hidden email].
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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CA%2B298Ujr7FMNSKWzRaBXjA%3DgMYYLL%3D9yX%3DEjJ5dJBtiS-qzKEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: The getText atom

Selenium - Developers mailing list
In reply to this post by Simon Stewart
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 "<a href="https://www.w3.org/TR/webdriver/#get-element-text" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.w3.org%2FTR%2Fwebdriver%2F%23get-element-text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8AU57BhcGbPqYBMirgrXbhxZ1sA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.w3.org%2FTR%2Fwebdriver%2F%23get-element-text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8AU57BhcGbPqYBMirgrXbhxZ1sA&#39;;return true;">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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: The getText atom

Simon Stewart
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 <[hidden email]> 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 "<a href="https://www.w3.org/TR/webdriver/#get-element-text" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.w3.org%2FTR%2Fwebdriver%2F%23get-element-text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8AU57BhcGbPqYBMirgrXbhxZ1sA';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.w3.org%2FTR%2Fwebdriver%2F%23get-element-text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8AU57BhcGbPqYBMirgrXbhxZ1sA';return true;">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 [hidden email].
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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/2BE8CF2F-CD76-4B44-94A0-36A3A41AA5A3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: The getText atom

Selenium - Developers mailing list
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.

The code is checked in however: https://github.com/SeleniumHQ/selenium/blob/ceaf3da79542024becdda5953059dfbb96fb3a90/javascript/webdriver/atoms/element.js#L122

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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="YhzlipKgAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">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 "<a href="https://www.w3.org/TR/webdriver/#get-element-text" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.w3.org%2FTR%2Fwebdriver%2F%23get-element-text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8AU57BhcGbPqYBMirgrXbhxZ1sA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.w3.org%2FTR%2Fwebdriver%2F%23get-element-text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8AU57BhcGbPqYBMirgrXbhxZ1sA&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="YhzlipKgAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">selenium-developers+unsubscribe@....
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

shadow_dom_test.html (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The getText atom

Simon Stewart
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

On Fri, Jan 13, 2017 at 5:03 PM, 'Mark Charsley' via Selenium Developers <[hidden email]> wrote:
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 <[hidden email]> 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+unsubscrib[hidden email].
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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYGMH4OakHidqk9LNTAJWyaBczxrcpHrwRGHnKCvXmCFXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: The getText atom

Selenium - Developers mailing list


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

On Fri, Jan 13, 2017 at 5:03 PM, 'Mark Charsley' via Selenium Developers <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="Cn8v8l7mAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">selenium-...@googlegroups.com> wrote:
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.

The code is checked in however: <a href="https://github.com/SeleniumHQ/selenium/blob/ceaf3da79542024becdda5953059dfbb96fb3a90/javascript/webdriver/atoms/element.js#L122" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FSeleniumHQ%2Fselenium%2Fblob%2Fceaf3da79542024becdda5953059dfbb96fb3a90%2Fjavascript%2Fwebdriver%2Fatoms%2Felement.js%23L122\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE4ozExj3XUiXHB98QLy6Ss4H-iJw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FSeleniumHQ%2Fselenium%2Fblob%2Fceaf3da79542024becdda5953059dfbb96fb3a90%2Fjavascript%2Fwebdriver%2Fatoms%2Felement.js%23L122\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE4ozExj3XUiXHB98QLy6Ss4H-iJw&#39;;return true;">https://github.com/SeleniumHQ/selenium/blob/ceaf3da79542024becdda5953059dfbb96fb3a90/javascript/webdriver/atoms/element.js#L122

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 <[hidden email]> 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 "<a href="https://www.w3.org/TR/webdriver/#get-element-text" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.w3.org%2FTR%2Fwebdriver%2F%23get-element-text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8AU57BhcGbPqYBMirgrXbhxZ1sA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.w3.org%2FTR%2Fwebdriver%2F%23get-element-text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8AU57BhcGbPqYBMirgrXbhxZ1sA&#39;;return true;">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+[hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="Cn8v8l7mAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">selenium-developers+unsubscribe@....
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/dd787f2e-f3a4-469b-98f4-2a0201be302c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: The getText atom

Simon Stewart
On Mon, Jan 16, 2017 at 10:30 AM, 'Mark Charsley' via Selenium Developers <[hidden email]> 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

On Fri, Jan 13, 2017 at 5:03 PM, 'Mark Charsley' via Selenium Developers <[hidden email]> wrote:
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 <[hidden email]> 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+unsubscrib[hidden email].
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.

--
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+unsubscrib[hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/dd787f2e-f3a4-469b-98f4-2a0201be302c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYGyLB6QyCRLfafOJCLuF9y3t-uLAdN9UFu_U31zvrFphA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: The getText atom

Selenium - Developers mailing list
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

On Monday, January 16, 2017 at 2:36:39 PM UTC, Simon Stewart wrote:
On Mon, Jan 16, 2017 at 10:30 AM, 'Mark Charsley' via Selenium Developers <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="ptoEZUuSAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">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

On Fri, Jan 13, 2017 at 5:03 PM, 'Mark Charsley' via Selenium Developers <[hidden email]> wrote:
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.

The code is checked in however: <a href="https://github.com/SeleniumHQ/selenium/blob/ceaf3da79542024becdda5953059dfbb96fb3a90/javascript/webdriver/atoms/element.js#L122" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FSeleniumHQ%2Fselenium%2Fblob%2Fceaf3da79542024becdda5953059dfbb96fb3a90%2Fjavascript%2Fwebdriver%2Fatoms%2Felement.js%23L122\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE4ozExj3XUiXHB98QLy6Ss4H-iJw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FSeleniumHQ%2Fselenium%2Fblob%2Fceaf3da79542024becdda5953059dfbb96fb3a90%2Fjavascript%2Fwebdriver%2Fatoms%2Felement.js%23L122\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE4ozExj3XUiXHB98QLy6Ss4H-iJw&#39;;return true;">https://github.com/SeleniumHQ/selenium/blob/ceaf3da79542024becdda5953059dfbb96fb3a90/javascript/webdriver/atoms/element.js#L122

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 <[hidden email]> 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 "<a href="https://www.w3.org/TR/webdriver/#get-element-text" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.w3.org%2FTR%2Fwebdriver%2F%23get-element-text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8AU57BhcGbPqYBMirgrXbhxZ1sA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.w3.org%2FTR%2Fwebdriver%2F%23get-element-text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8AU57BhcGbPqYBMirgrXbhxZ1sA&#39;;return true;">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+[hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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+[hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.


--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="ptoEZUuSAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">selenium-developers+unsubscribe@....
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/selenium-developers/dd787f2e-f3a4-469b-98f4-2a0201be302c%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/dd787f2e-f3a4-469b-98f4-2a0201be302c%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/dd787f2e-f3a4-469b-98f4-2a0201be302c%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/selenium-developers/dd787f2e-f3a4-469b-98f4-2a0201be302c%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/44ab2b4e-85c6-4508-9489-ee99b2e2a212%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: The getText atom

Simon Stewart
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

On Tue, Jan 17, 2017 at 8:36 AM, 'Mark Charsley' via Selenium Developers <[hidden email]> wrote:
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

On Monday, January 16, 2017 at 2:36:39 PM UTC, Simon Stewart wrote:
On Mon, Jan 16, 2017 at 10:30 AM, 'Mark Charsley' via Selenium Developers <[hidden email]> 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

On Fri, Jan 13, 2017 at 5:03 PM, 'Mark Charsley' via Selenium Developers <[hidden email]> wrote:
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 <[hidden email]> 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+unsubscrib[hidden email].
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.

--
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+unsubscrib[hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
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+unsubscrib[hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/dd787f2e-f3a4-469b-98f4-2a0201be302c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/44ab2b4e-85c6-4508-9489-ee99b2e2a212%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYEm4spHOP5xCsGEZvfpm6yxcL0c-6CbQCCTF9Q2N6LdRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: The getText atom

Selenium - Developers mailing list
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

On Tuesday, January 17, 2017 at 11:51:21 AM UTC, Simon Stewart wrote:
David pointed me at the <a href="https://platform-status.mozilla.org/#shadow-dom" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fplatform-status.mozilla.org%2F%23shadow-dom\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG7bf9h884clKRmxJlJZoRAOmmhsw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fplatform-status.mozilla.org%2F%23shadow-dom\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG7bf9h884clKRmxJlJZoRAOmmhsw&#39;;return true;">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

On Tue, Jan 17, 2017 at 8:36 AM, 'Mark Charsley' via Selenium Developers <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="5J_cwdrXAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">selenium-...@googlegroups.com> wrote:
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

On Monday, January 16, 2017 at 2:36:39 PM UTC, Simon Stewart wrote:
On Mon, Jan 16, 2017 at 10:30 AM, 'Mark Charsley' via Selenium Developers <[hidden email]> 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

On Fri, Jan 13, 2017 at 5:03 PM, 'Mark Charsley' via Selenium Developers <[hidden email]> wrote:
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.

The code is checked in however: <a href="https://github.com/SeleniumHQ/selenium/blob/ceaf3da79542024becdda5953059dfbb96fb3a90/javascript/webdriver/atoms/element.js#L122" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FSeleniumHQ%2Fselenium%2Fblob%2Fceaf3da79542024becdda5953059dfbb96fb3a90%2Fjavascript%2Fwebdriver%2Fatoms%2Felement.js%23L122\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE4ozExj3XUiXHB98QLy6Ss4H-iJw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FSeleniumHQ%2Fselenium%2Fblob%2Fceaf3da79542024becdda5953059dfbb96fb3a90%2Fjavascript%2Fwebdriver%2Fatoms%2Felement.js%23L122\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE4ozExj3XUiXHB98QLy6Ss4H-iJw&#39;;return true;">https://github.com/SeleniumHQ/selenium/blob/ceaf3da79542024becdda5953059dfbb96fb3a90/javascript/webdriver/atoms/element.js#L122

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 <[hidden email]> 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 "<a href="https://www.w3.org/TR/webdriver/#get-element-text" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.w3.org%2FTR%2Fwebdriver%2F%23get-element-text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8AU57BhcGbPqYBMirgrXbhxZ1sA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.w3.org%2FTR%2Fwebdriver%2F%23get-element-text\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE8AU57BhcGbPqYBMirgrXbhxZ1sA&#39;;return true;">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+[hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/selenium-developers/f5c89db8-17ab-4c34-ba06-d7d819df0f5d%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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+[hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/selenium-developers/7a9433db-c713-42fa-ae86-4fcfc8761e47%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.


--
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+[hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/selenium-developers/dd787f2e-f3a4-469b-98f4-2a0201be302c%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/dd787f2e-f3a4-469b-98f4-2a0201be302c%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/dd787f2e-f3a4-469b-98f4-2a0201be302c%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/selenium-developers/dd787f2e-f3a4-469b-98f4-2a0201be302c%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="5J_cwdrXAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">selenium-developers+unsubscribe@....
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/selenium-developers/44ab2b4e-85c6-4508-9489-ee99b2e2a212%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/44ab2b4e-85c6-4508-9489-ee99b2e2a212%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/44ab2b4e-85c6-4508-9489-ee99b2e2a212%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/selenium-developers/44ab2b4e-85c6-4508-9489-ee99b2e2a212%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/d71fc8fa-dbb9-4ca2-9ca4-819c97f3e904%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.