Re: [DOM3Events] Identifying mouse events derived from touch events

On Tue, Sep 2, 2014 at 3:01 PM, Robert Kroeger <rjkroege@google.com> wrote:

>
> On Wed, Aug 27, 2014 at 7:26 AM, Rick Byers <rbyers@chromium.org> wrote:
>
>> Hi,
>> Web developers have long struggled to reliably identify which mouse
>> events are actually derived from touch events.  Sites need to know this to
>> avoid double handling (eg. on both a touchend and click event), and have
>> often just ignored all mouse events on a browser that supports touch events
>> - seriously breaking functionality on devices with both a mouse and
>> touchscreen.
>>
>> We (blink team) have tried for over a year to address this problem
>> through evangelism (eg. encouraging
>> <http://www.html5rocks.com/en/mobile/touchandmouse/> calling
>> <https://www.youtube.com/watch?v=DujfpXOKUp8> preventDefault on handled
>> touch events to suppress the generated mouse events).  The situation has
>> improved, but it's still a major problem (eg. it's the reason we haven't
>> yet been able to rationalize Chrome's support for TouchEvents
>> <https://code.google.com/p/chromium/issues/detail?id=392584> across
>> devices, and the reason the IE team says
>> <http://lists.w3.org/Archives/Public/public-touchevents/2014Jul/0025.html> they
>> implement touch events only on phones, not laptops).
>>
>> I recognize now that avoiding
>> <https://code.google.com/p/chromium/issues/detail?id=115475#c13> adding
>> a new simple API for this was a *big mistake*.  There are legitimate
>> reasons why the available workarounds are inadequate. For example, you may
>> want to suppress/ignore mouse events without disabling browser behavior
>> like focusing, activating links, etc.  Or some listeners may want to ignore
>> certain mouse events whose handling is redundant with that for touch events
>> without affecting other listeners (perhaps in other components written by
>> other developers).
>>
>> After considering a number of more general alternatives
>> <https://docs.google.com/a/chromium.org/document/d/1-ZUtS3knhJP4RbWC74fUZbNp6cbytG6Wen7hewdCtdo/edit#>,
>> I'd like to propose a very simple and targeted *addition to MouseEvent:* *a
>> boolean 'derivedFromTouchEvent' property*.  Note that this intentionally
>> says the event represents input that was already reported via some other
>> event, NOT that the event represents input from a touchscreen device (eg.
>> browsers on Android send touch events for mouse and stylus, not just touch
>> input).
>>
>
> I think this is a good choice for letting a site determine if the mouse
> events are derived from touch input.
>
> Is it worth considering one possible extension: given a derived event, is
> it worth letting the UA specify to the site what was the origin of the
> event?
>

Thanks Rob.  What sort of "origin"s were you imagining here?  Do you mean
just other possibilities than just "from touch" (eg. 'click' events can be
'derived' from keyboard input)?  Or do you mean for the derived-from-touch
case, more details on the original action like "derived from a tap gesture"?

With this we could encourage sites to trivially transform this common
>> broken pattern:
>>
>> if (‘ontouchstart’ in window)
>>   document.addEventListener(‘touchstart’, doStuff);
>> else
>>   document.addEventListener(‘mousedown’, doStuff);
>>
>>
>> Into this:
>>
>> document.addEventListener(‘touchstart’, doStuff);
>> document.addEventListener(‘mousedown’, function(e) {
>> if (!e.derivedFromTouchEvent) doStuff(e);
>> });
>>
>>
>> This new API can be trivially polyfilled on browsers (like Safari) which
>> never support mouse and touch input at the same time with just:
>>
>> if (!('derivedFromTouchEvent' in MouseEvent.prototype))
>>
>>     MouseEvent.prototype.derivedFromTouchEvent = ‘ontouchstart’ in window;
>>
>>
>> See this document
>> <https://docs.google.com/a/chromium.org/document/d/1-ZUtS3knhJP4RbWC74fUZbNp6cbytG6Wen7hewdCtdo/edit#>
>> for more details and other alternative proposals.
>>
>> Thanks,
>>    Rick
>>
>
>