Intent to Ship: Uncancelable Touch Events During A Fling (intervention)

[Lan Wei]

Contact emails

lan...@chromium.org, tdre...@chromium.org, dtap...@chromium.org, rby...@chromium.org

Spec

https://w3c.github.io/touch-events/#cancelability

https://docs.google.com/document/d/1jXaK9JcqpZtiNMoXvmgJ6sZ6K04wCO1VKIqvJeFM8wI/

Summary

Passive Event Listeners is a way to improve scroll performance by unblocking scrolling on touch and wheel event listeners, so that scrolling happens immediately while the events are processed by javascript. alexclarke@ proposed that we should treat all the touchstart and first touchmove event listeners as passive while there’s an active fling animation on the touched layer.

After running this intervention as a field trial on 50% users on both Canary and Dev since M54, the 98th percentile of the first gesture scroll update latency on Android devices is reduced by 6.69%.

Link to chrome-input discussion

https://groups.google.com/a/google.com/d/msg/chrome-input/_tyas1nNmfk/lxevE5O3CAAJ

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

Yes

Ongoing technical constraints

No

Demo link

This page tests that the touch event is cancelable if a fling is active on a different layer than the touched layer.

http://output.jsbin.com/fajekiw/quiet/

This page tests that the touch event’ cancelable attribute is set to false when there is an active fling on the touched layer.

https://output.jsbin.com/qegemu/quiet/

Compatibility risk

Safari sets touch events’ cancelable property to be false while there is an active fling on the touched layer, so calling ‘preventDefault’ does not have any effect on them. Our intervention matches its behavior.

Firefox and IE/Edge do not invoke any touch event listener at all when there is an active fling on the touched layer. We do not prefer this approach, because we want it behave consistent with our passive event listeners.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=646069

Entry on the feature dashboard

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

Requesting approval to ship?
Yes

[Lan Wei]

Sorry, I should not say that our fling intervention behavior matches exactly with Safari.

We made several testing pages, 

https://output.jsbin.com/zacota/quiet, shows that Safari sets the touchmove events' cancelable property to false, when there is an active flinging animation, but the touchstart events' cancelable is still true. If we are calling preventDefault on every other touchmoves, we can still see scrolling continuously happen during an active fling (https://jsbin.com/jegobo/quiet/).

[Chris Harrelson]

LGTM1

On Mon, Dec 5, 2016 at 12:28 PM, 'Lan Wei' via blink-dev <blin...@chromium.org> wrote:

Sorry, I should not say that our fling intervention behavior matches exactly with Safari.

We made several testing pages, 

https://output.jsbin.com/zacota/quiet, shows that Safari sets the touchmove events' cancelable property to false, when there is an active flinging animation, but the touchstart events' cancelable is still true. If we are calling preventDefault on every other touchmoves, we can still see scrolling continuously happen during an active fling (https://jsbin.com/jegobo/quiet/).

On Mon, Dec 5, 2016 at 9:00 AM Lan Wei <lan...@google.com> wrote:

Contact emails

lan...@chromium.org, tdre...@chromium.org, dtap...@chromium.org, rbyers@chromium.org

--
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+unsubscribe@chromium.org.

[Lan Wei]

Compatibility risk

We tested on three pages,

 https://output.jsbin.com/jegobo/quiet/ (Testing if preventDefault actually prevent scrolling, when there is an active fling)

 https://output.jsbin.com/zacota/quiet (Checking if the touch events are cancelable while there is an active fling)

 http://output.jsbin.com/fajekiw/quiet/ ((Testing if we can prevent touch events happening while there is an active fling on a different layer than the touched layer)

We observe the below behaviors when there is an active fling,

	‘cancelable’ attribute of touch events only when there is an active fling on the touched layer		Can ‘preventDefault’ on touch events?
	Touch Start	Touch Move	All touch events
Chrome	false	false	no
Safari	true	false	no
Edge	true	true	no
Firefox	true	true	no

[Dimitri]

LGTM2.

[Jochen Eisinger]

lgtm3

On Thu, Dec 8, 2016 at 7:23 PM Dimitri <dgla...@chromium.org> wrote:

LGTM2.

[Lan Wei]

I missed some cases in the previous email. Below chart summarizes all the cases.

When we touch on a layer on which there is an active fling animation, the touch events have four pssible outcomes,

Cancelable: the 'cancelable' attribute is true, and we can call ‘preventDefault’ on it.

Uncancelable: the 'cancelable' attribute is false, and we cannot call ‘preventDefault’ on it.

Not Dispatched: the events are not dispatched, so the event listeners will not be invoked.

Uncancelable but marked cancelable: the 'cancelable' attribute is true, but we cannot call ‘preventDefault’ on it, so it should be treated as 'uncancelable'.

To sum up, no matter how the 'cancelable' attribute is set and if the event is dispatched, when we try to scroll on a layer which has an active fling happening, some touches (touch starts) can be cancelled in Safari, but not in any other browser.

Browser	Touch Start	Touch Move
Chrome	Uncancelable	Uncancelable
Safari	Cancelable	Uncancelable
Edge	Uncancelable but marked cancelable	Uncancelable but marked cancelable
Firefox	Not Dispatched	Not Dispatched

[Rick Byers]

[getting caught up after vacation]

Thanks for the additional clarifications Lan.  This now paints a good picture that the interop and compat risks are probably low enough to make the perf benefit worth it.  Also note that this change will mean all implementations of pointer events will be interoperable around this (can't change touch-action during a flag and expect it to take effect on a repeat-fling on the same scroller).  Personally I favor high interoperability of pointer events over worrying about edge cases in touch events since it's only pointer events that really has any hope of achieving great interop (since Apple won't participate in standardization in this space).

Anyway you've got your 3 LGTMs, just wanted to indicate I support this too.

Contact emails

lan...@chromium.org, tdre...@chromium.org, dtap...@chromium.org, rbyers@chromium.org