Wait for request animation frame after scrolling into view in element click/clear/send keys

[juliandescottes]

All three commands of the interaction module involve performing a scroll into view in case the element we want to interact with is not in view.

However, even with behavior instant, the document handles scrolls in a queue, so there's no guarantee the scroll is synchronously executed, and that a corresponding scroll event is emitted in the page. If the test page has some logic attached as a listener to the "scroll" event which is necessary to make the element in view (eg changing the visibility of the element or its parent), then we would need to wait a bit after the scroll in order to perform the next is in view check.

This originally came from https://bugzilla.mozilla.org/show_bug.cgi?id=2014538, where the tested application uses a panel list widget which does react to the scroll event. Without waiting after the scroll, this application cannot use element click / clear / send keys to test their widget.

The current suggestion was to at least wait for the next animation frame. But we can have other strategies.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Wait for request animation frame on action commands.

The full IRC log of that discussion

<AutomatedTester> topic: Wait for request animation frame on action commands
<AutomatedTester> github: https://github.com//issues/1944
<AutomatedTester> jdescottes: this last topic is to do with handling actions that will scroll the element into view
<AutomatedTester> ... and the browser does the scrolls in an async way
<sadym> q+
<AutomatedTester> ... so how do you want to handle this... or do we just do the simple way because old tests are already handling the timing and we might suddnely break things
<AutomatedTester> ack next
<jimevans> q+
<AutomatedTester> sadym: this sounds like a breaking change that I would rather have jgraham or simonstewart to answer
<jgraham> q+
<AutomatedTester> ack next
<AutomatedTester> jimevans: I would prefer people to use bidi but I think we need to solve scrolling in bidi so not sure we can have bidi as a solution just yet
<AutomatedTester> ack next
<jdescottes> q+
<AutomatedTester> jgraham: I was looking at CSSOM has scroll into view returns a promise but I don't think it's handled
<AutomatedTester> ... I think there is a bit of history that when we change things like this that people rely on current behaviour
<AutomatedTester> ... it would be good to test the change on a large test suite
<AutomatedTester> ack next
<jgraham> q+
<AutomatedTester> jdescottes: if we update classic it would need an opt ok. If there is a promise on the spec then great. There are a use case where a series of JS fired when the scroll happened. I am happy to have bidi do scroll into a view that relies on this promise and if there are more complicated cases that they handle that themselves
<AutomatedTester> ack next
<AutomatedTester> jgraham: for actions we handle the click event before we move on to the next part of the action chain
<AutomatedTester> ... so then with a scroll we wait for the promise to return and then then event loop to spin
<jdescottes> q+
<AutomatedTester> ... I think there would be some logical idea that after the scroll action that we spin the event loop to handle events that could have been created by that action
<AutomatedTester> ack next
<AutomatedTester> jdescottes: would we consider this for classic or just bidi
<AutomatedTester> jgraham: if we put scroll into actions which would make it new so there would not be a compatibility things
<AutomatedTester> ... which means we can work in classic or classic. If we were changing the API that is there its hard to existing API because people could be relying ont hat behaviour
<AutomatedTester> ... so we can add it here and have it spin the event loop
<jgraham> RRSAgent: make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2026/02/11-webdriver-minutes.html jgraham