Intent to Deprecate and Remove: Gesture Scroll DOM events

[Mehdi Kazemi]

Contact emails

sko...@chromium.org,meh...@chromium.org,blink-inter...@google.com

Explainer

None

Specification

None. Not a standard feature.

Summary

Gesture Scroll DOM events, namely “gesturescrollstart”, “gesturescrollupdate” and “gesturescrollend” are non-standard APIs, which were added to Blink for use in plugins, but it appears they were also exposed to the web unintentionally. Plugins are no longer web-exposed since the deprecation of Google Native Client (NaCl).

WebKit Bug: https://bugs.webkit.org/show_bug.cgi?id=92281

Changelog: https://bugs.webkit.org/attachment.cgi?id=155046&action=prettypatch

Motivation

Currently, this API doesn’t work in all situations. It only works when there is a non-composited scroller. These events are related to compositing state, and compositing state is not meant to have observable behavior impact and in Blink will vary depending on display type and other factors.

Blink component

Blink>Scroll

TAG review

TAG review status

Not applicable

Risks

No other engine supports these events, so we do not expect interoperability issues.

As for compatibility, usage data from Canary, Dev and Beta channels show that usage is very low, around 0.000015% (gesturescrollstart gesturescrollupdate gesturescrollend). For this reason we would like to just remove it, without any deprecation period.

Is this feature fully tested by web-platform-tests?

No

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1293994

Estimated milestones

No milestones specified

[Rick Byers]

Oh yikes, these got exposed to the web and we never noticed? Scary. I may have had a hand in that a long time ago, sorry! I forget the details, but remember something about NaCL and maybe Flash support for touch scrolling. Presumably none of that matters anymore now that Flash and NaCL are gone.

I can imagine scenarios where they might be useful to have, but I guess being main thread only makes them pretty useless (almost all gesture scrolls are threaded these days). Anyway, given the near zero usage, lack of a spec, main-thread only behavior and lack of evidence of anyone talking about these events I'd consider this extremely safe to remove (more of a bug fix than a deprecation).  LGTM1

Thanks for discovering this and cleaning it up!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAASN_%3DmnFnKhp7WQNYiVztF%3Dhr1jpzSTo1x02nXZtysnO2GUMQ%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_BmVOXxKibPwSF%2BNn9u76AUXdE09fjE7ohWVF7iqUvMg%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8qg6SbsZNX0SU6JK%3D_7WhsBkuGLpEHpKGpEAXNXnN%3DLA%40mail.gmail.com.

[K. Moon]

It's not quite true that plugins aren't Web-exposed anymore; PDF support still appears as a plugin. Is there any impact to PDF viewers?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/982bc373-1ad8-595a-0433-999d49257cec%40gmail.com.

[Steve Kobes]

This change shouldn't impact Chromium's PDF viewer, which is currently doing its own gesture detection based on wheel and touch events.

(There has also been some discussion of adapting the PDF viewer to use "native" scrolling.  This change doesn't create any roadblocks for that effort, since the gesture scroll events would be handled in C++ and not in JS.)

[K. Moon]

Thanks!

[Rick Byers]

Good point, thanks for asking!

[Joe Medley]

What are the milestones for deprecation and removal? Also does this have a status entry? I can't find one.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

On Thu, Jun 9, 2022 at 9:11 AM Mehdi Kazemi <meh...@chromium.org> wrote:

[Steve Kobes]

On Mon, Jun 13, 2022 at 1:19 PM Joe Medley <jme...@google.com> wrote:

What are the milestones for deprecation and removal?

This removal is on track for M105.

 

Also does this have a status entry? I can't find one.

That's my fault, I had advised Mehdi that I did not think a chromestatus entry was needed here.

For my understanding: is it our policy to have a status entry for all removals (even if minor)?

[Joe Medley]

Yes, that is correct. 

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Joe Medley]

FYI, the status entry would have let you generate the text for the intent. The marginal cost for using the status entry is small, but it boosts the profile of the deprecation/removal. Most deprecations/removals are pretty insignificant, but we don't like to assume that no one needs to know about it. 

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.