Re: Chrome change in TouchEvent feature detection

AFAIK "if("TouchEvent" in window)" has always been true in Chrome - at
least for the past year or so.  No change there.  To be honest I was
initially confused about this myself - hiding the interface object would be
really weird and I was happy to see that as far as I could tell we hadn't
been doing that (it was our logic for failing createEvent("TouchEvent") I
was getting confused with myself).

The developer-visible change in Chrome 57 is that touch listeners installed
with addEventListener when "'ontouchstart' in window" is false will now
start to fire for physical touch input (instead of only via events
generated from DevTools touch emulation and JavaScript, where this was
already possible).

Rick

On Sat, Dec 24, 2016 at 3:03 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 22/12/2016 20:40, Rick Byers wrote:
>
>> On Thu, Dec 22, 2016 at 4:54 AM, Olli Pettay <olli@pettay.fi
>> <mailto:olli@pettay.fi>> wrote:
>>
> [...]
>
>>     `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).
>>
>
> If I'm understanding this right, `if("TouchEvent" in window)` will now
> always return true then (even without touchscreen)? So if devs are using
> that particular sniff in a misguided "if it's true, it means there's touch,
> so I can just listen to touch" their sites will still now potentially fail
> for mouse users all the time (not just when there's an additional
> touchscreen present)?
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>