disallow preventDefault() on TouchMoves during overscroll

Touch events sent to a page can be either blocking or non-blocking. A blocking touch event means that the page calls preventDefault() to prevent the browser from turning the touch into a scroll. TouchMove events start out blocking until the first event in a sequence isn’t preventDefaulted and causes scrolling. Chromium currently reverts the touchevent stream back to blocking so that pages can override browser default overscrolling behavior. This feature causes overscrolling to be non-blocking.

Demo

Documentation

Specification

No public standards discussion

Status in Chromium

Blink


Enabled by default (tracking bug) in:

  • Chrome for desktop release 85
  • Chrome for Android release 85
  • Android WebView release 85

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.

  • Shipped/Shipping
  • No signal
  • Shipped/Shipping
  • No signals

Owners

Intent to Prototype url

Intent to Prototype thread

Comments

Blocking touch events are bad for performance because the browser may need to wait on a reply from the busy main thread before scrolling. Blocking touchMoves during the overscroll behavior predates the CSS overscroll-behavior API which allows declaratively disabling browser overscroll behaviors. The “revert to blocking on overscroll” behavior is particularly problematic in the common case of infinite scrolling streams where the user may reach the end of loaded content but can continue to scroll once more content is loaded. This proposal is to avoid reverting to blocking touchmoves on overscrolling so that touchmoves are never cancelable once scrolling begins. Pages can use overscroll-behavior to block browser overscrolling actions like Pull-to-Refresh and Overscroll Glow. Internal data shows that roughly 8.5% sessions with scrolls encounter this at least briefly and we also have a telemetry benchmark that regularly hits this issue. This was landed on June 9th in crrev/c/2182426, and then suggested we send this intent to ship instead because of the user facing behaviour change. If this isn’t approved we’ll revert it before the beta branch point, but no complaints or regressions from this change so far.

Last updated on 2020-10-25