Re: Phasing out mouse compatibility events on tap?

On Fri, Jan 16, 2015 at 11:01 AM, PhistucK <phistuck@gmail.com> wrote:

> Do you dispatch mouse events for websites that do not register any mouse
> event listener (are there such websites? I mean, ones that only register
> touch events)?
> By "dispatch", I mean, exercise the overhead and code path for hit testing.
>

We do.  In theory we could have a fast-path (we have optimizations for
sites without touch handlers, but there the benefit is much bigger because
it can avoid a trip to the renderer process entirely).  But I doubt there's
sufficient benefit to justify the complexity.  I don't have data handy, but
I suspect the number of sites with touch handles but no mouse handlers is
quite small.

☆*PhistucK*
>
> On Fri, Jan 16, 2015 at 5:51 PM, Rick Byers <rbyers@chromium.org> wrote:
>
>> [Context: Matt raised a good
>> <https://docs.google.com/a/chromium.org/document/d/1-ZUtS3knhJP4RbWC74fUZbNp6cbytG6Wen7hewdCtdo/edit#heading=h.rbcct8al2kop>
>> point in my 'identifying mouse events derived from touch' document that the
>> compatibility mouse events we send on tap may be causing more confusion
>> than benefit.]
>>
>> I don't think we want to try to phase out sending 'click' on tap (since
>> 'click' really means 'activate' - eg. used for the enter key also), and so
>> still need a way to identify which click events are derived from touch
>> events.  But there really is no good reason to be firing mousemove,
>> mouseover, mouseenter, mousedown, and mouseup for every tap outside of
>> legacy.  At a minimum they add a bunch of extra overhead and complexity
>> (especially since we typically need to do a hit-test after each) and
>> provide absolutely no value to a modern touch-optimized web experience.
>> But worse, I think they add conceptual complexity and confusion.
>>
>> I believe lots of websites still rely on these events for compat, but we
>> should start thinking about how we could phase them out.  Eg. maybe we
>> should define an API to enable/disable them and work towards making
>> disabling the default - at least in modern scenarios?  We could pretty
>> easily get some experience with this now - eg. a flag in chromium which
>> disables the mouse* events on tap for sites we identify as not needing
>> "desktop workarounds" (i.e. based on the viewport)?  Matt, would doing
>> something like this address your concern?
>>
>> input-dev, WDYT - should we try to do some implementation experimentation
>> in chromium here?  TECG, do you think this is a problem worth tackling /
>> potentially designing an API for?
>>
>> Rick
>>
>>
>