[blink-dev] Intent to Implement: Unblocking Scroll when Main Thread Unresponsive

[Timothy Dresser]

Contact Email: tdre...@chromium.org

Spec

For details on this intervention, see the design doc here.

This intervention is explicitly allowed by the current Touch Event spec.

For maximum scroll performance, a user agent may not wait for each touch event associated with the scroll to be processed to see if it will be canceled. In such cases the user agent should generate touch events whose cancelable property is false, indicating that preventDefault cannot be used to prevent or interrupt scrolling.

Summary

We intend to replace the Touch Ack Timeout with an intervention which forces touch events to be uncancellable when the main thread is busy, allowing scrolling to take place immediately on the compositor thread.

Initially, we'll launch this as a Finch trial on Canary and Dev.

Motivation

80% of javascript event listeners that block scroll (touchstart, touchmove, wheel, mousewheel) do not actually prevent it.

On Android, in the 99’th percentile, it takes over 450ms to begin a scroll. In these extremely slow cases, the user experience would be better if the user agent didn’t bother waiting for the main thread.

For this intervention, we identify events which will cause scroll where the main thread is unlikely to respond quickly, and make them uncancellable, allowing scrolling to occur smoothly on the compositor thread. The only way to avoid this intervention will be to use touch-action to declaratively prevent scrolling, or ensure that the page’s main thread remains responsive.

Interoperability and Compatibility Risk:

Edge and Firefox have similar functionality to our existing Touch Ack Timeout. There is some risk here to rationality of the web platform, but we believe this intervention is strictly more rational than the existing Touch Ack Timeout, primarily since it allows developers to observe that the modified events are uncancellable.

Safari:

Safari has some odd behavior around long running touch event handlers, but it isn’t consistent.

Edge:

Edge appears to have something equivalent to the Touch Ack Timeout (verified experimentally on http://rbyers.github.io/touch-timeout.html)

Firefox:

The APZ content response timeout is equivalent to our Touch Ack Timeout.

https://bugzilla.mozilla.org/show_bug.cgi?id=1247280

Ongoing technical constraints

No.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug

crbug.com/684703

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5754213783044096

Requesting approval to ship?

Requesting approval to perform Finch Trial on Canary and Dev.

[Philip Jägenstedt]

Perhaps this is well covered in the design doc, but could you say something about how "Expected Queueing Time" is predicted? If it's based on historical data over the past few seconds, I guess that a site that only occasionally does something very expensive on the main thread would have a low expected queueing time right up until that point? Is it possible to write a page where the new heuristic results in strictly worse user-visible scroll performance, or will the Touch Ack Timeout have to remain exactly as-is?

[Timothy Dresser]

The design doc doesn't cover the computation of expected queueing time particularly thoroughly, but it does define it. Expected Queueing Time "looks at how long an input event would have been delayed for on average, if it had arrived in the past second."

You're correct that there are cases where this behaves worse than the existing Touch Ack Timeout, but we believe they're relatively rare in practice, and there are many cases where this behaves better. Overall, we expect this will be a win for rationality, and not degrade user experience on average.

We'll run a finch trial to verify that switching from the touch ack timeout doesn't negatively impact user experience before shipping.

Note that this is now considered blocked on getting touch action hit testing onto the impl thread. In order to ensure that touch-action allows preventing scrolling in these cases, and that we don’t block forever waiting for the result of getting the touch action on the main thread, we need to do the touch action hit test on the compositor.

[Philip Jägenstedt]

In other words, the Touch Ack Timeout will be removed, and not stay around as a fail-safe for the cases where the new heuristic gets it wrong? That sounds good, having both would be even harder to reason about I reckon.

[Timothy Dresser]

That's correct - the current plan is to only ship this if we're able to remove the Touch Ack Timeout, based on results from the finch trial.

[Philip Jägenstedt]

Sounds great, hope this all works out!