Missing "scroll into view" Actions primitive

[shs96c]

Mid-way through executing a sequence of actions it's useful to be able to scroll an element into view. A "scroll into view" primitive would enable this.

[andreastt]

Is this meant to target level 2? It seems more like an omission from the actions API than scope creep to me.

[shs96c]

Yeah, it's level 2. @jgraham and I discussed this on the IRC channel a few months ago. Adding it requires us to add new functionality, and that's something we're not meant to do in the CR period.

[gsnedders]

IMO, we should follow what CSSOM View does here and offer all three of scrollIntoView, scrollTo, and scrollBy on elements.

[shs96c]

Something semantically equivalent would be good. There is definitely a difference between scrolling an element into view, and scrolling a page by a certain amount. Reading CSSOM, it looks like scrollTo and scrollBy both end up delegating to scroll.

On Wed, May 23, 2018 at 7:06 PM Geoffrey Sneddon [email protected] wrote:

IMO, we should follow what CSSOM View does here and offer all three of scrollIntoView, scrollTo, and scrollBy on elements.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/webdriver/issues/1005#issuecomment-391444158, or mute the thread https://github.com/notifications/unsubscribe-auth/AABuRbPlQIWBBT33O2saYrH91F34gGO3ks5t1aUbgaJpZM4O0r59 .

[gsnedders]

Element.prototype.scroll is identical to Element.prototype.scrollTo; both Element.prototype.scrollBy and Element.prototype.scrollTo call an internal function that does the actual scrolling.

[andreastt]

I spoke to some users earlier today and they wanted the ability to scroll both by an amount and by web element, e.g. scroll(web element reference). AIUI scrollTo and scrollBy both take coordinates.

Some observations:

• scrollTo takes ScrollIntoViewOptions: I’m assuming we’d use the same options we do for Element Send Keys and Element Click.
• scrollBy takes either an options dictionary (top/left), or X/Y coordinates.

This all sounds straight forward, but I have two open questions:

1. Are we fine with pixels make out the unit of scrolling? What if the user wants to scroll one height of the viewport (100vh)?
2. The user would have to build up a mental model of where the viewport is at the moment, and writing interoperable tests across different device configurations would be hard.

[whimboo]

Here the resolution from TPAC (minutes):

Add general "scroll" action primitive that takes the same input as pointerMove, except for origin it will not take the "pointer" variant, but it will have one called "relative" that is relative to the viewport. x/y offset will be given in pixels, and it will take the same ScrollIntoViewOptions defaults as the high level Element Click command.

[christian-bromann]

fwiw: WebdriverIO has a custom implementation for this behavior that we have battle tested: https://github.com/webdriverio/webdriverio/blob/main/packages/webdriverio/src/commands/element/scrollIntoView.ts. It will fall back to the Web API if the remote environment doesn't support it.