Re: Chrome change in TouchEvent feature detection

On Thu, Dec 22, 2016 at 4:54 AM, Olli Pettay <olli@pettay.fi> wrote:

> On 12/22/2016 04:16 AM, Rick Byers wrote:
>
>> Hey,
>> One of the big problems with TouchEvents has been that some websites
>> still assume that support for the TouchEvent API implies a mobile device
>> without
>> any mouse support (and so clicking with a mouse will not work).
>>
>> Chrome has long had a hack to partially work around this where we enable
>> touch support (including the TouchEvent API) only when we detect the
>> presence
>> of a touchscreen on startup.  With our work on pointer events and trying
>> to address complaints of customers who plug in a touchscreen after startup,
>> we've recently overhauled that logic <https://bugs.chromium.org/p/c
>> hromium/issues/detail?id=644318>.  The principle now is that we're
>> applying the
>> hack JUST to the legacy APIs used primarily for feature detection [1].
>> Sites that follow the guidance
>> <https://hacks.mozilla.org/2013/04/detecting-touch-its-the-
>> why-not-the-how/> of always listening to both TouchEvents and
>> MouseEvents using modern
>> addEventListener style instead of the DOM0 'on' attributes will now work
>> reliably without being impacted by the web compat hack here.  Sites that
>> condition to special-case "'ontouchstart' in window" will continue to
>> behave as before.
>>
>> IMHO this is a good compromise between platform rationality and the web
>> compat issues and I'm pretty disappointed I didn't think to try this years
>> ago
>> ;-).  If this works then rather than rely on the (often buggy and
>> unhelpful) touchscreen detection, I'd probably attempt to simplify this
>> <https://bugs.chromium.org/p/chromium/issues/detail?id=392584> by having
>> the legacy feature detection APIs consistently disabled on desktop and
>> enabled on mobile (while still being overridable from chrome://flags for
>> special cases).
>>
>> If this sticks, I'd like to encourage other browsers with desktop
>> implementations to give it a try and get it formalized as expected behavior
>> in the
>> spec.  Thoughts?
>>
>> Rick
>>
>> [1] For completeness the set of APIs that are hidden in Chrome when there
>> is no touchscreen are
>> <https://cs.chromium.org/search/?q=%22RuntimeEnabled%3DTouch
>> EventFeatureDetection%22&sq=package:chromium&type=cs>:
>>   on GlobalEventHandlers (window, Document, HTMLElement, SVGElement):
>>     ontouchstart, ontouchmove, ontouchend, ontouchcancel
>>   Document.createTouch
>>   Document.createTouchList
>>   document.createEvent("TouchEvent")    (throws)
>>
>>
>
> So event handlers are hidden but can one still set them? Or how does this
> actually work?
>

No, the legacy DOM0 properties do not exist.  If you write to them, they
will not get invoked.  But people generally use addEventListener these days
anyway, so although that's inconsistent with other events, I don't see it
as much of a problem in practice.

Are event handlers just not there at all and Document.create* either when
> touchscreen isn't detected initially?
>

Correct.  The APIs just aren't present.

What about interface objects? Are they visible in the global scope?
>

Yes, the Touch and TouchEvent interface objects are already always visible
and the constructors can be invoked (no need to have a real touch screen in
order to do testing with JS-synthesized touch events).

`if ("TouchEvent" in window)` is one way to detect the feature (IMO the
> right one even), though not sure how often
> that is used.


Right, hopefull that's what people are relying on to detect support for
TouchEvents, and using the other common patterns (mainly "'ontouchstart' in
window" just as a hack to detect mobile devices).