Intent to Deprecate and Remove: legacy touch event APIs on desktop devices

[Ella Ge]

Contact emails

eir...@chromium.org

Summary

Disable legacy touchevent APIs on desktop devices by default, including:

- ontouch* members on window, document, Element
- document.createTouch, document.createTouchList
- document.createEvent("TouchEvent")

Motivation

We currently have chrome://flags/#touch-events default to “Automatic”, which enable these TouchEvent APIs if we detect a touchscreen on chrome startup. However, some sites use these APIs as mobile/touch-only device detection. That causes some sites behave differently between non-touchscreen laptop and touchscreen laptop, see discussion in git.

We’d like to change touch-events flag default to “disable”, so the APIs mentioned above will be disable by default on desktop devices. When in mobile emulation mode in devtools these APIs will be enabled.

Interoperability and Compatibility Risk

The risk should be small. We only disable these APIs on desktop, mobile sites won’t be affected. Only desktop sites that rely on touch event without mouse/pointer events support will be affected (which likely already broken).

Edge has similar flag, which is “disabled” by default, these APIs are disabled by default too.

Firefox default to “Automatic”, similar to chrome’s current behavior: enable these APIs when detect a  touch screen.

Alternative implementation suggestion for web developers

Sites wishing to do real cross-device TouchEvent feature detection should use if (window.TouchEvent).

Desktop sites can use PointerEvent APIs to support both touch and mouse.

Usage information from UseCounter

Don’t have a UseCounter.

OWP launch tracking bug

crbug.com/392584

Entry on the feature dashboard

https://www.chromestatus.com/feature/4764225348042752

Requesting approval to remove too?

Yes

--

Ella

[Rick Byers]

There's a lot of nuance and history to this, but I totally support it.  I'm going to abstain from my API owner role though since I'm the one who proposed making this change.

We've LONG struggled with the problem that many sites use feature detection like "if ('ontouchstart' in window)" to mean both "does this device support touch input" and "is this device a phone where touch is the only input" (in fact this was basically the first problem I started looking into when working on ChromeOS touchscreen support back in 2011).  When a touchscreen laptop passes these feature detects it has the benefit of touch input working on some sites it might not otherwise, with the downside of mouse input often being broken.  The heuristic of Chrome looking for a touchscreen device on startup has never been very satisfactory (steady stream of complaints from users who don't consider themselves to really be touchscreen users - eg. due to a touchscreen emulation driver installed by Visual Studio, or more commonly touchscreen laptop users who don't actually use their touchscreen much, with the unpredictability of dynamic attachment scenarios like KVM switches).

Originally I think this was the better trade off, but we probably crossed a threshold a year ago or so where it no longer makes sense:

• Pointer Events have now been supported long and broadly enough that sites which really care about a great multi-modal experience (i.e. basically every single major online mapping site) are at least falling back to using them when touch events aren't available (if not preferring them).  
• All the patterns historically used for this feature detection are considered legacy / discouraged.  We've now got TouchEvent constructors, additional reasons to prefer addEventListener over the dom0 attributes, etc.
• Despite some predictions otherwise, touch is still not dominant on laptops, and most touchscreen laptop users don't actually use their touchscreen very much (mouse is clearly primary).
• Edge has shipped touch event support, but still is unwilling to enable it on desktop due to these compat problems

In terms of the interop risk, we've talked about this off and on with the other browsers for some time, and have an open spec issue to try to agree on something.  Perhaps we should draft a PR for the spec to precisely capture the change we're proposing here?  I'm fairly optimistic that this change will prove to be the best tradeoff:

• It eliminates all of the device-detection heuristics.
• The changes it causes are generally what users prefer - touchscreen laptops will have the mouse work more often, but the touchscreen work less often.
• It successful, it's likely something Microsoft and Mozilla would be happy to follow us on and then we'd finally have interop here (for the OSes which support touchscreens - Safari is irrelevant).
• It has a very simple work-around for sites that really just want to know "are touch events supported (alongside other types of events)" - just use "if (window.TouchEvent)".

One sad thing about this design is that it explicitly treats desktop differently from mobile, when in practice there isn't necessarily a significant distinction (eg. large android tablets vs. small ChromeOS convertibles).  But that ship has really already sailed with the question of whether or not to send an "Android" UserAgent string and support <meta viewport> tags, so as long as we're 100% consistent  with those I don't think this makes it any worse.

Another sad thing is that it is weird to have the events actually be supported (eg. via addEventListener) without the on* attributes reliably existing.

So I support trying to change the default behavior of this flag, but leaving the flag in (for now) for users who really do want legacy sites to treat their touchscreen laptop like a phone. 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGbAJuGiw4mmknus3crn2QjePizEZhdDKZUUiJsFieu5nENUvg%40mail.gmail.com.

[eir...@chromium.org]

Thanks Rick, your explanation is much more clear than mine.

> change the default behavior of this flag, but leaving the flag in (for now)

Yeah, that's the current plan.

[Domenic Denicola]

> One sad thing about this design is that it explicitly treats desktop differently from mobile, when in practice there isn't necessarily a significant distinction (eg. large android tablets vs. small ChromeOS convertibles). But that ship has really already sailed with the question of whether or not to send an "Android" UserAgent string and support <meta viewport> tags, so as long as we're 100% consistent with those I don't think this makes it any worse.

The information that these kind of things are tied together is new and interesting to me. It would probably be a good thing to add to the spec, especially from the perspective of allowing new implementations to successfully work with web content. I'd imagine it as a series of "should" requirements, instead of "must".

> Another sad thing is that it is weird to have the events actually be supported (eg. via addEventListener) without the on* attributes reliably existing.

I tried to find the reasoning why we wouldn't just disable all touch event-related functionality on desktop, but didn't see it in either the original post or your reply. It certainly seems like it would be cleaner. Is there a history behind why we'd prefer to disable some APIs, but not all?

[eir...@chromium.org]

touch events for addEventListener is not controlled by the flag and touch screen detection. They are available whether there is a touch screen or not. I think we still want touch events function in desktop with touch screen. It's possible to also disable addEventListener("touchevents") but more sites will be broken.

[Domenic Denicola]

From: eir...@chromium.org [mailto:eir...@chromium.org]

> touch events for addEventListener is not controlled by the flag and touch screen detection. They are available whether there is a touch screen or not. I think we still want touch events function in desktop with touch screen. It's possible to also disable addEventListener("touchevents") but more sites will be broken.

Right, I understand that's how it currently works, but I'm not sure why. Do you have data (or just examples) on the "more sites will be broken" idea? Perhaps from Edge's experience?

[eir...@chromium.org]

I just check Edge's behavior, and they seems also disable addEventListener when the flag is disable. 

I'm not familiar with the history why we don't disable them in Blink. 

Rick, do we want to disable the addEventListener too? or is there any reason we don't do that?

[Rick Byers]

If Pointer Events had substantial adoption, then yes just effectively deprecating TouchEvents completely to "mobile-only" could be an option worth considering seriously (and still something we could consider in the future).  But the reality today is that there are still a lot of sites / libraries which support touch only via TouchEvents.  There are also still some types of UI which are still possible only with Touch Events and not with Pointer Events (eg. Facebook's "hold then drag to select reaction"). So doing this would definitely break a lot more for users of touchscreen laptops (much larger page views and unique sites impact).  Concretely, on Windows 0.3% of PageViews invoke at least one touchstart listener while only 0.03% invoke a pointerdown listener for touch input (TouchStartFired and PointerDownFiredForTouch UseCounters).  Also about 4% of all URLs in HTTP Archive contain the string "touchstart" while only 0.5% contain the string "pointerdown".  I don't think we have any hard data on what fraction of this relies on the broken feature detection patterns, but anecdotally I believe it to be a minority (we could do a finch trial to verify, or just watch how the above metrics change in dev channel if/when Ella lands this change).

Also it's a trivial fix for a developer to update their feature detection if their code did actually support touch+mouse correctly than to switch to pointer events (easy developer adaptation).

Another reason not to deprecate TouchEvents from desktop entirely is that that would be a much larger likely permanent fork between the web on desktop and the web on mobile.  This feature-detection hack seems like a pretty small wart to me, and something I could imagine someday changing mobile to match as well (basically acknowledging that "'ontouchstart' in window" was widely mis-used to mean something other than "does this browser support touch events" and so is now lost to us as an API we can make behave rationally).

Thoughts?

[Chris Harrelson]

Some questions.

1. Will Gecko be willing to come along for the ride? Sounds like they currently match/almost match Chromium's behavior.

2. Am I correct that Edge already does the better behavior you want to change to in Chromium? Or is there more to do to match their behavior?

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_AVr89QbNw__j_KgsdObucPX%2BogXThHkF5oFN0-bgV%2BA%40mail.gmail.com.

[Rick Byers]

Those are good questions.  I added a comment to the spec issue to ask explicitly, we'll see what they say.

On Fri, Nov 10, 2017 at 11:32 AM, Chris Harrelson <chri...@chromium.org> wrote:

Some questions.

1. Will Gecko be willing to come along for the ride? Sounds like they currently match/almost match Chromium's behavior.

Right, and they say they've struggled with some of the same compat issues we have that make the conditional-by-hardware-presence design unattractive.  

2. Am I correct that Edge already does the better behavior you want to change to in Chromium? Or is there more to do to match their behavior?

No, Edge on desktop never enables touch events due to these compat problems (only Edge mobile).  They have the code and there's a flag users can use to turn it on.  The possibility of getting all the desktop browsers aligned around the same (somewhat weird but at least deterministic) behavior is what I'm most excited by in this proposal. 

[eir...@chromium.org]

Update: FF replied that they support this change. Link

[Rick Byers]

Chris, WDYT?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c0e4915-e74f-4c4c-9388-90a6c5a76693%40chromium.org.

[Chris Harrelson]

On Thu, Nov 23, 2017 at 11:08 AM, Rick Byers <rby...@chromium.org> wrote:

Chris, WDYT?

LGTM then to try to make this change. Sorry for the slow response.

 

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

[eir...@chromium.org]

I still need 2 more LGTM for this change. The CL here is ready.  Is it possible that we can get this approved in this year?

[Malte Ubl]

One thing to note: please explicitly say that the implementation will be reactivated when Chrome DevTools mobile emulation is on. Otherwise that mode would get pretty useless.

I personally feel this is too early. I've not perceived any momentum in the webdev community towards adoption of Pointer Events since they provide no widely perceived (you might disagree but that is the perception) value.

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/CAFUtAY_AVr89QbNw__j_KgsdObucPX%2BogXThHkF5oFN0-bgV%2BA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c0e4915-e74f-4c4c-9388-90a6c5a76693%40chromium.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+...@chromium.org.

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

--
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/75d7e82b-04aa-48fd-a8ee-ae834bb49ae0%40chromium.org.

[eir...@chromium.org]

This change will not affect devtool emulation mode. These APIs will be reactivated when Chrome DevTools mobile emulation is on.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c0e4915-e74f-4c4c-9388-90a6c5a76693%40chromium.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.

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

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

[Daniel Bratell]

The current situation where touch enabled web sites may or may not work on desktop devices depending on the web author's choice of code and the web browser is quite unsatisfactory. I'm not sure this is the best way out of that mess but maybe it is.

It will break web pages, and it will make web pages work.

It will split APIs between mobile and non-mobile browsers.

So that said, I think it's best to go ahead but be prepared to reverse course if needed.

LGTM2

/Daniel

 (Presto based desktop Opera had similar problems and if I remember correctly we disabled touch events in the desktop browser in 2011 to avoid getting mobile sites). 

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/CAFUtAY_AVr89QbNw__j_KgsdObucPX%2BogXThHkF5oFN0-bgV%2BA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c0e4915-e74f-4c4c-9388-90a6c5a76693%40chromium.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+...@chromium.org.

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

--
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/75d7e82b-04aa-48fd-a8ee-ae834bb49ae0%40chromium.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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc0f8e63-1caa-4d98-aca3-14ca504b3c9e%40chromium.org.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zbf6mc1grbppqq%40cicero2.linkoping.osa.

[Peter Bojak]

I think this would cause touch drag/pan/zoom interaction stop working in d3.js projects on desktop:

• https://github.com/d3/d3-drag#drag_touchable
  
• https://github.com/d3/d3-zoom/blob/master/README.md#zoom_touchable
  

(Assuming the touch detection functions aren't overwritten by the author.)