Intent to Remove: user gesture on touch scroll

258 kali dilihat
Langsung ke pesan pertama yang belum dibaca

Rick Byers

belum dibaca,
11 Okt 2016 22.34.2611/10/16
kepadablink-dev

Primary eng (and PM) emails

rby...@chromium.org


Link to “Intent to Deprecate” thread

Here


Summary

Only consider a touch event a "user gesture" when it's the touchend associated with a tap.


Motivation

We've seen multiple examples of poorly written / malicious ads which trigger navigation for touch scrolls (either on touchstart or all touchend events). If a 'wheel' event can't open a pop-up, then really touch scrolling shouldn't either. The previous change was the minimal thing necessary to stop the worst cases (cross-origin iframes), but now I'd like to attempt to make this more consistent / more thorough.


Compatibility Risk

There is a non-trivial risk that this will break some scenarios - media not playing on touch, pop-ups not opening on touch. However it's unclear what fraction of that is desired vs. undesired behavior. Safari already silently fails to open pop-ups in all of these scenarios, so we shouldn't be breaking anything that works in Safari.

Usage information from UseCounter

I've attempted to quantify the risk by measuring when a user gesture is used from within a touchstart, touchmove or (non-tap) touchend handler. Results on Android Stable (as % of PageVisits) are as follows:

TouchStartUserGestureUtilized: 0.16%

TouchMoveUserGestureUtilized: 0.015%

TouchEndDuringScrollUserGestureUtilized: 0.05%


All of these numbers are higher than I hoped and are worrying. I've tried to look at how they could be a measurement error, but haven't come up with anything wrong. Ideally I'd have some way to find specific examples to investigate, but I can't come up with any practical way to find them (hard to simulate real user input, etc.). My gut instinct is that since Mobile Safari already doesn't support these cases, this is going to be a mix of intentional abuse, subtle websites bugs whose impact isn't user visible, and some small amount of real breakage in Chrome-specific code.


After sitting on this for a few months, thinking through different options and talking to a few folks, I think the best path forward is to just try to ship this. The breakage is still bounded to a low number, and Safari compatibility means this is potentially a net predictability improvement. If more than one real-world website is discovered to be broken in a non-trivial way during beta, I'll revert and re-evaluate.


OWP launch tracking bug

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


Entry on the feature dashboard

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


Jochen Eisinger

belum dibaca,
12 Okt 2016 03.21.1112/10/16
kepadaRick Byers, blink-dev
lgtm1

Elliott Sprehn

belum dibaca,
12 Okt 2016 04.15.0812/10/16
kepadaRick Byers, blink-dev

Does this break light switch widgets? I totally support not granting a gesture if the page actually scrolled, but if the author has touch-action set and you toggle a switch that should trigger a gesture. If we don't you produce a strange situation where tapping the switch does the action (ex. Plays audio) but sliding it doesn't. It's possible the UX is worse here in Safari, but I don't think we should copy their behavior if it means limiting a popular UX paradigm like this.

Rick Byers

belum dibaca,
12 Okt 2016 10.31.5412/10/16
kepadaElliott Sprehn, blink-dev
No, my plan was not to break light switch widgets that trigger on touchend (regardless of whether a scroll occurred or not).  I.e. the change I want to make is described as the "new proposed intervention" in this doc, but I was sloppy in my summary of it below (thanks for pointing that out).  Re-written inline.

On Wed, Oct 12, 2016 at 4:15 AM, Elliott Sprehn <esp...@google.com> wrote:

Does this break light switch widgets? I totally support not granting a gesture if the page actually scrolled, but if the author has touch-action set and you toggle a switch that should trigger a gesture. If we don't you produce a strange situation where tapping the switch does the action (ex. Plays audio) but sliding it doesn't. It's possible the UX is worse here in Safari, but I don't think we should copy their behavior if it means limiting a popular UX paradigm like this.


On Oct 11, 2016 7:34 PM, "Rick Byers" <rby...@chromium.org> wrote:

Primary eng (and PM) emails

rby...@chromium.org


Link to “Intent to Deprecate” thread

Here


Summary

Only consider a touch event a "user gesture" when it's the touchend associated with a tap.


Correction: Only consider a touch event a user gesture when it's a touchend not associated with a scroll (i.e. was a tap, a drag where scrolling had been disabled by touch-action or canceling of prior touch events, or some multi-finger gesture which similarly did not trigger scrolling or zooming).

Elliott Sprehn

belum dibaca,
12 Okt 2016 11.36.3512/10/16
kepadaRick Byers, blink-dev

Oh great! Glad I was just confused here. :)

Chris Harrelson

belum dibaca,
12 Okt 2016 12.49.0412/10/16
kepadaElliott Sprehn, Rick Byers, blink-dev
LGTM2

--
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.

Steve Kobes

belum dibaca,
12 Okt 2016 13.11.3112/10/16
kepadaRick Byers, blink-dev
LGTM overall.

On Tue, Oct 11, 2016 at 7:33 PM, Rick Byers <rby...@chromium.org> wrote:

We've seen multiple examples of poorly written / malicious ads which trigger navigation for touch scrolls (either on touchstart or all touchend events).


I think navigation in general doesn't require a user gesture.  Are there plans to change that, or do we only care about the popups?

Rick Byers

belum dibaca,
12 Okt 2016 13.31.1912/10/16
kepadaSteve Kobes, blink-dev
There are separate interventions to further restrict when navigation can happen (eg. see japhet@'s most recent intent and others on the tracking sheet) but it's complex and full of challenging web compat tradeoffs.

Philip Jägenstedt

belum dibaca,
21 Okt 2016 09.33.2621/10/16
kepadaRick Byers, Steve Kobes, blink-dev
Is this still waiting for 3xLGTM? LGTM3!

Rick Byers

belum dibaca,
21 Okt 2016 09.53.3321/10/16
kepadaPhilip Jägenstedt, Steve Kobes, blink-dev
Thank you!

Yes I figured (having been swamped myself and behind on intents) I had no right to complain about the delay ;-)

Rick

Joe Medley

belum dibaca,
21 Okt 2016 13.00.1321/10/16
kepadaRick Byers, Philip Jägenstedt, Steve Kobes, blink-dev
Rick,

Do you think maybe this deserves its own dashboard item?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

Rick Byers

belum dibaca,
7 Nov 2016 17.57.0007/11/16
kepadaJoe Medley, Philip Jägenstedt, Steve Kobes, blink-dev
Sorry for the delay Joe, I finally got back to this.  Yes, a dedicated entry (rather than combining first step) is probably a good idea, thanks - done.

The change for this has now landed.

anna.e...@gmail.com

belum dibaca,
13 Des 2017 11.47.0913/12/17
kepadablink-dev
Hi,

Because of removing the touch gestures of touch start and touch end, on Chrome browser and Windows 10, the stylus does not work and because of which our web application of whiteboard is non functional. Please help us resolve this issue ASAP

Regards,
Annarao Kulkarni

Dave Tapuska

belum dibaca,
13 Des 2017 12.08.4313/12/17
kepadaanna.e...@gmail.com, blink-dev
Annarao,

Please open a new issue cc'ng me and tagging it as Blink>Input. We can discuss the issue that you are seeing there. From your email it isn't clear what version you are using and what website. There were some recent (Chrome 62) changes with respect to stylus and I'm wondering if you are confusing those changes with this user gesture behaviour. It is best we discuss this on a bug.

dave.

--
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.
Balas ke semua
Balas ke penulis
Teruskan
0 pesan baru