New issue
Advanced search Search tips

Issue 872341 link

Starred by 1 user
Status: Available
Owner: ----
Cc:
chaopeng@chromium.org
sunyunjia@chromium.org
bokan@chromium.org
majidvp@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 3
Type: Feature



Sign in to add a comment

Scrolling APIs should return a promise

Project Member Reported by majidvp@chromium.org, Aug 8 
CSSWG agreed [1] to change all scrolling APIs (e.g., scrollTo, scrollIntoView, ...) to return a promise instead of void. The promise is resolved when the scrolling operations is deemed complete (finished, aborted). The promise will be resolved with an argument that has details about the final position and perhaps other important information.

This is very useful to enable actions that need to occur after scripted scroll e.g., scroll the element into view (smoothly) and then do X.

The exact details remain to be specified but once those are agreed upon we should consider implementing this.


[1] https://github.com/w3c/csswg-drafts/issues/1562#issuecomment-389586317

Comment 1 by bokan@chromium.org, Aug 8 

Note - this is something we're struggling with in tests and I'm thinking about how to address this quarter. An example of why this isn't simple:

You might want to scroll the main document by 'x' pixels and then scroll some newly revealed scroller. Our testing routines in gpuBenchmarking return a promise that resolves when the gesture is finished. But that's not good enough. Between that time, we still have to wait for:

- The gesture events to be delivered to and processed by the renderer
- If handled on the main thread, those changes to be propagated to the compositor via a commit
- Wait until the changes are propagated to the screen by being activated to the active impl tree.

Once it's in the active tree, new gestures will have all the updated state available to them. 

My initial thought is that we should create some infrastructure in Blink/Chrome to allow us to tell when a change has been propagated to the active tree. We could then reuse that in this new API, our own internal testing APIs, and ChromeDriver (recently had DevTools team reach out to me about this). I'll have to flesh out the details soon.

Comment 2 by chaopeng@chromium.org, Oct 17

Cc: chaopeng@chromium.org

Comment 3 by bokan@chromium.org, Nov 2 

FYI: I've written a proposal on how to solve this that should work for both scrolling APIs and tests: https://docs.google.com/document/d/1BX8V3ciUs8fV-x8dBI6rdz5_2dAmewgrUxIcWILXvGA/edit#
►

Sign in to add a comment