Re: Enabling Touch Events everywhere

Thanks Jacob!
When doing this outreach it may help to say that Chrome plans to enable
touch events all the time (tracked by http://crbug.com/392584), so this
will likely break them on mouse-only machines before too much longer.  Also
using Chrome with a mouse on a device with a touchscreen is increasingly
becoming a "default configuration" for us.  When we get user complaints of
such issues, the users generally have not noticed that they can work around
the issue by using their touchscreen (a substantial minority of touchscreen
laptop users almost never use their touchscreen in our experience).

Note that your bug reports say: "you typically should be able to see these
issues in Chrome by enabling Touch Events in the developer tools".  That's
technically 100% correct.  Due to technical limitations we can't completely
enable the DOM0 touch event properties
<https://code.google.com/p/chromium/issues/detail?id=133915> dynamically
through the devtools (although we play some tricks to help catch the common
use cases).  The best way to test is to force the touch event API to be
enabled with chrome://flags/#touch-events.

Can you share a little about the methodology you used to find these, and
how you classified "broken"?  The most obvious failure mode is when
clicking things just doesn't work (often making the site unusable).  This
used to be very common, but in our experience is much less common these
days.  The more minor issues are things like non-essential hover menus
which are disabled on touchscreen laptops but (arguably) a desirable UI for
mouse users.

I've been planning on doing an automated test where I load up each of the
top sites homepages and compare the number of mouse event handlers
installed with and without touch event support being present.  I expect the
sites whose handler counts differ will correlate well with those that are
badly broken, but I'm not sure how reliable this will be in practice.
 Thoughts?

Matt, is there anything our DevRel team can do to help here?  This is
really just continuing the evangelism we started with this html5rocks
article <http://www.html5rocks.com/en/mobile/touchandmouse/> and my Google
I/O talk <https://developers.google.com/events/io/sessions/361772634>.

Thanks,
   Rick


On Fri, Sep 5, 2014 at 5:33 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>
wrote:

>  As we’ve discussed before, there’s still significant issues that block
> us from shipping Touch Events everywhere. Primarily, these are attributed
> to patterns like:
>
>
>
> if('touchstart' in document.body) {
>
>     elm.addEventListener('touchstart',fn1);
>
> }else{
>
>     elm.addEventListener('mousedown', fn2); //only registered on
> browsers/devices without Touch Events
>
> }
>
>
>
> We’ve only begun to test sites for this issue. In testing the top 100
> sites, we found 10 sites with broken mouse functionality when Touch Events
> is exposed. So we expect this to trend to significant impact across the
> larger web.
>
>
>
> For impacted sites that we’ve found, we’ve started tracking site outreach
> over at webcompat.com.  I’ll keep the group updated on what success we
> have here. Though I suspect asking sites to change their code for a problem
> that doesn’t exist in browsers’ default configuration (aside from using
> Chrome with a mouse on a device that also has a touchscreen) may be
> difficult.  We’d appreciate any support from others in this group in
> finding, diagnosing, and outreaching here so that we can hopefully one day
> make the type system consistent across devices.
>
>
>
> https://github.com/webcompat/web-bugs/issues/309
>
> https://github.com/webcompat/web-bugs/issues/304
>
> https://github.com/webcompat/web-bugs/issues/306
>
> https://github.com/webcompat/web-bugs/issues/307
>
> https://github.com/webcompat/web-bugs/issues/308
>
> https://github.com/webcompat/web-bugs/issues/310
>
> https://github.com/webcompat/web-bugs/issues/311
>
> https://github.com/webcompat/web-bugs/issues/305
>
>
>
> Note that there are a couple other sites that Microsoft has conversations
> with already, so we didn’t duplicate these on webcompat.
>
>
>
> -Jacob
>