Phasing out mouse compatibility events on tap?

[Rick Byers]

[Context: Matt raised a good 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

[PhistucK]

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.

☆PhistucK

[Rick Byers]

On Fri, Jan 16, 2015 at 11:01 AM, Patrick H. Lauke <re...@splintered.co.uk> wrote:

Quickfire gut reaction (beyond "dammit, do you want to remove all interesting topics from my presentation/workshop?")

Heh heh - I guess it's kinda the point of  the TECG to make input handling so easy/obvious that it puts you out of a job <grin>. 

On 16/01/2015 15:51, Rick Byers wrote:

I believe lots of websites still rely on these events for compat,

Which I believe is their entire "raison d'etre"...I'm sure it was a pragmatic solution taken by Apple at the time.

Absolutely. 

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?

Two issues:

- the events are there for compat with "legacy" content...which is usually unlikely to be updated now. So default should be to have the compat events still enabled by default, no?

Yes, we can't go breaking the web.  But we might be able to identify some subset where we could disable these events by default with little/no negative impact, but I guess that's unlikely.  It can be useful to try some (non-shipping-by-default) experiments though to help us learn about the patterns of dependence here.  Eg. I'd hope that the vast majority of sites with mobile viewports aren't relying on these today (but even then it's probably not anywhere near the ~99.98% of page views we'd likely need to even consider making this the default).

- how do you programmatically define/recognise (with heuristics) a "modern scenario"? I'd be weary of automagic behavior here. Also, there may be scenarios where even modern (recently built) sites somehow make use of mouse compat events (don't ask me why...) somehow (even if just to simplify their handling of stuff, e.g. setting a flag on touch* event, but leaving the actual functionality to happen on mouse* event).

Perhaps looking on load if any mouse listeners have been registered may be an initial approach (though it would fall foul of any listeners that are dynamically added at a later date).

Yeah this is hard and probably impossible to come up with something we could actually ship to people.  I don't think we should use presence of handlers as a signal - that can result in 'heisenbugs' where the act of adding an event handler changes the behavior of what you're trying to observe :-(

So for now I think the most productive discussion is "in the long-run, do we think you should be able to write responsive web apps that don't fire these events, and if so what might an API to opt-out of them look like?".

 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

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

[Rick Byers]

On Fri, Jan 16, 2015 at 11:01 AM, PhistucK <phis...@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.

[Patrick H. Lauke]

On 16/01/2015 16:14, Rick Byers wrote:
> On Fri, Jan 16, 2015 at 11:01 AM, Patrick H. Lauke
> <re...@splintered.co.uk <mailto:re...@splintered.co.uk>> wrote:
>
> Quickfire gut reaction (beyond "dammit, do you want to remove all
> interesting topics from my presentation/workshop?")
>
>
> Heh heh - I guess it's kinda the point of the TECG to make input
> handling so easy/obvious that it puts you out of a job <grin>.

The contortions you guys go through just so you can stick with your "no,
Pointer Events have problems" ("no we won't admit it's purely because of
Apple's reluctance") attitude is admirable nonetheless ;)

[Arthur Stolyar]

Can we just have document.disableCompatibilityMouseEvents = true; for "very, very, very" expirienced developer which know what thay do? I mean if developer plan to use touchevents and knows that compatibility events will mess his/her work, why developer cannot just disable them at all by him/herself?

--

@nekrtemplar

[Rick Byers]

On Fri, Jan 16, 2015 at 11:21 AM, Arthur Stolyar <nekr....@gmail.com> wrote:

Can we just have document.disableCompatibilityMouseEvents = true; for "very, very, very" expirienced developer which know what thay do? I mean if developer plan to use touchevents and knows that compatibility events will mess his/her work, why developer cannot just disable them at all by him/herself?

Yep, that's one possible API shape.  I hope that it's not just for "very" experienced developers though.  I'd like to believe that the easy-to-use frameworks of the future would do this by default so that even the least experienced developers just never need to think about it.

I'm not sure an API on document is the best pattern though - it implies that the decision can be made for the page as a whole, when often a page is built out of components with different expectations/assumptions.  Maybe it should be a CSS property instead?  Or maybe it should be a preventMouseEvents() method on TouchEvent?

--

@nekrtemplar

[PhistucK]

I am actually not sure this proposal is even the right way forward, really.

There should not be touch only websites and without the compatibility mouse events, or Pointer Events, you must implement event registration for every input. I think the way forward is to avoid that.

☆PhistucK

[Arthur Stolyar]

2015-01-16 18:25 GMT+02:00 Rick Byers <rby...@chromium.org>:

On Fri, Jan 16, 2015 at 11:21 AM, Arthur Stolyar <nekr....@gmail.com> wrote:

Can we just have document.disableCompatibilityMouseEvents = true; for "very, very, very" expirienced developer which know what thay do? I mean if developer plan to use touchevents and knows that compatibility events will mess his/her work, why developer cannot just disable them at all by him/herself?

Yep, that's one possible API shape.  I hope that it's not just for "very" experienced developers though.  I'd like to believe that the easy-to-use frameworks of the future would do this by default so that even the least experienced developers just never need to think about it.

I'm not sure an API on document is the best pattern though - it implies that the decision can be made for the page as a whole, when often a page is built out of components with different expectations/assumptions.  Maybe it should be a CSS property instead?  Or maybe it should be a preventMouseEvents() method on TouchEvent?

--

@nekrtemplar

I think we had disscussed something simillar sometime ago for PointerEvents. Browsers already has some weird ways do stop compatibility events and those ways, as time shows for us -- does not work well. I mean it would be good to have ability to disable such behavior per region, but only if it really will work that way as expected. I do not exactly want that API to be on document, but as a developer I really want it at all. This topic comes here time-by-time in an year (few years?) already and nothing done yet. So I would have some basic, simple way/solution for it now, which really work and at least might help to developers of professional/big apps, then framework developer might utils that API too and then all others. 
--

@nekrtemplar

[Patrick H. Lauke]

On 16/01/2015 16:36, PhistucK wrote:
> I am actually not sure this proposal is even the right way forward, really.
>
> There should not be touch only websites and without the compatibility
> mouse events, or Pointer Events, you must implement event registration
> for every input. I think the way forward is to avoid that.

It's not about preventing mouse events in general, but suppressing only
the generation of those that are the result of a touch interaction
(meaning devs still should register handlers for keyboard, mouse, touch,
but at least they won't have to de-dupe mouse events that were the
result of a touch)

[Arthur Stolyar]

2015-01-16 18:36 GMT+02:00 PhistucK <phis...@gmail.com>:

I am actually not sure this proposal is even the right way forward, really.

There should not be touch only websites and without the compatibility mouse events, or Pointer Events, you must implement event registration for every input. I think the way forward is to avoid that.

I am pretty sure that disabling of compatibility events will not disable real mouse events, so they will be fired anyway. This API is not for touch only web sites, but for websites which understand how to handle touch events separately along side with mouse/keyboard events.

--

@nekrtemplar

[PhistucK]

These compatibility events can be considered as the 'legacy Pointer Events'. You can rely on them instead of registering events for every pointer inputs.

While these can be a problem when you do implement event registration for every pointer input, this is (unfortunately? fortunately? I am not sure) atypical.

The short term way of improving this would be to add a property on compatibility mouse events that regards them as simulated and the long term of improving this would be Pointer Events.

I think adding this developer toggler would be bad for two reasons -

- It encourages touch (or specific input) only implementations (you get better performance if you disable compatibility mouse events and your primary audience is smartphones with touch screens, so this is enough. The hell with the rest).

- It can interfere with third party scripts you may add (even analytical ones), or any code that you do not control.

☆PhistucK

[Patrick H. Lauke]

On 16/01/2015 16:46, PhistucK wrote:
> These compatibility events can be considered as the 'legacy Pointer
> Events'. You can rely on them instead of registering events for every
> pointer inputs.

Problem is that the compat mouse events are not equivalent. For
instance, you cannot track finger movements by using mousemove compat
events, as moving the the finger on the touchscreen simply will not
generate them.

> The short term way of improving this would be to add a property on
> compatibility mouse events that regards them as simulated

This is being discussed separately, but yes.

> and the long
> term of improving this would be Pointer Events.

As Google and Apple have indicated that they will not be implementing
PE...this discussion is about improving touch events for now. I agree
that PE are the way forward though for these scenarios.

[Arthur Stolyar]

Hi PhistucK,

2015-01-16 18:46 GMT+02:00 PhistucK <phis...@gmail.com>:

These compatibility events can be considered as the 'legacy Pointer Events'. You can rely on them instead of registering events for every pointer inputs.

While these can be a problem when you do implement event registration for every pointer input, this is (unfortunately? fortunately? I am not sure) atypical.

The short term way of improving this would be to add a property on compatibility mouse events that regards them as simulated and the long term of improving this would be Pointer Events.

Pointer Events are good, but we do not talk here about them.

 

I think adding this developer toggler would be bad for two reasons -

- It encourages touch (or specific input) only implementations (you get better performance if you disable compatibility mouse events and your primary audience is smartphones with touch screens, so this is enough. The hell with the rest).

This is possible aready by only using touchevents and do not using mouse events. Touch events does not has backcompatibility already, so if you will add right now only touch events, then desktop sites with mouse will not work anyway.

 

- It can interfere with third party scripts you may add (even analytical ones), or any code that you do not control.

Yes. This is why this choise whould be on developer side, not on browser side. So developer can disable compatibility events or not. This is only optimization and not one should/might use it.

In general, I agree about whole Pointer Events thing, but it's unfortunate to start talking about them again and again.

--

@nekrtemplar

[PhistucK]

Most websites do not explicitly need touch events, but only mouse events (with the compatibility mouse events). So in the same vein, perhaps document.disableTouchEvents should be added.

☆PhistucK

[Rick Byers]

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

Most websites do not explicitly need touch events, but only mouse events (with the compatibility mouse events). So in the same vein, perhaps document.disableTouchEvents should be added.

I think this is categorically untrue for the class of "websites" the blink team is focused on enabling (those with rich input interactions, i.e. material design).  The compatibility mouse events are useful only for detecting a tap.  Sites whose only input interaction is tapping are not our concern here (those are typically simple documents and already work well enough).  The simplest common example is an image carousel where you swipe between images.  These are extremely common on the web today and absolutely require listening for touch events.

[PhistucK]

Comments inline.

☆PhistucK

On Fri, Jan 16, 2015 at 6:55 PM, Arthur Stolyar <nekr....@gmail.com> wrote:

Hi PhistucK,

2015-01-16 18:46 GMT+02:00 PhistucK <phis...@gmail.com>:

These compatibility events can be considered as the 'legacy Pointer Events'. You can rely on them instead of registering events for every pointer inputs.

While these can be a problem when you do implement event registration for every pointer input, this is (unfortunately? fortunately? I am not sure) atypical.

The short term way of improving this would be to add a property on compatibility mouse events that regards them as simulated and the long term of improving this would be Pointer Events.

Pointer Events are good, but we do not talk here about them.

 

I think adding this developer toggler would be bad for two reasons -

- It encourages touch (or specific input) only implementations (you get better performance if you disable compatibility mouse events and your primary audience is smartphones with touch screens, so this is enough. The hell with the rest).

This is possible aready by only using touchevents and do not using mouse events. Touch events does not has backcompatibility already, so if you will add right now only touch events, then desktop sites with mouse will not work anyway.

Right, but this gives developer an incentive - use touch events, disable compatibility​ mouse events and you get better performance.

 

 

- It can interfere with third party scripts you may add (even analytical ones), or any code that you do not control.

Yes. This is why this choise whould be on developer side, not on browser side. So developer can disable compatibility events or not. This is only optimization and not one should/might use it.

This is problematic, too. You may not know whether third party scripts use them or not​ and these issues are usually hard to diagnose when you are not familiar with the situation ("I used this to get better performance but I do not really understand the changes it causes, I just copied and pasted it").

[Rick Byers]

On Fri, Jan 16, 2015 at 12:16 PM, PhistucK <phis...@gmail.com> wrote:

Comments inline.

☆Phistu

This, I think, is the best argument against adding such an API.  Developers of one component may use it and cause problems in another component that end up causing a lot of confusion and frustration.  If we can't reasonably expect to get rid of them consistently, then perhaps adding an API which just increases the number of things you need to understand actually makes the rationality of the platform worse, not better.

[Patrick H. Lauke]

On 16/01/2015 16:57, PhistucK wrote:
> Most websites do not explicitly need touch events, but only mouse events
> (with the compatibility mouse events). So in the same vein, perhaps
> document.disableTouchEvents should be added.

And why exactly? If your site does not register touch event handlers,
then it makes no difference/does not need to be suppressed.

[PhistucK]

Touch events contain much more data and granularity than mouse events. If you disable them, perhaps the logic or memory used for obtaining and storing that data can be suppressed and the memory usage or performance may improve.

☆PhistucK

[Rick Byers]

On Fri, Jan 16, 2015 at 12:22 PM, Patrick H. Lauke <re...@splintered.co.uk> wrote:

On 16/01/2015 16:57, PhistucK wrote:

Most websites do not explicitly need touch events, but only mouse events
(with the compatibility mouse events). So in the same vein, perhaps
document.disableTouchEvents should be added.

And why exactly? If your site does not register touch event handlers, then it makes no difference/does not need to be suppressed.

+1.

If the problem was simply "we can make things faster by never firing mouse events" then the "API" would be "don't listen for mouse events".  But it's more complex than that - the site WANTS mouse events, but only for actual mouse input.  So they need a way to selectively enable them.

Another option would be to somehow extend the addEventListener API to somehow indicate what level of compatibility you want.  Eg. "listen for mousedown events which aren't firedFrom('TouchEvent')".

[Rick Byers]

On Fri, Jan 16, 2015 at 12:24 PM, PhistucK <phis...@gmail.com> wrote:

Touch events contain much more data and granularity than mouse events. If you disable them, perhaps the logic or memory used for obtaining and storing that data can be suppressed and the memory usage or performance may improve.

Our measurements do not support this - we have to get the data in chromium in the first place in order to generate the gesture events that ultimately give rise to the compatibility mouse events.  BUT there is a significant cost associated with having the gresture events block on the touch event handling in blink.  This is why we already implement various optimizations which skip sending touch events to the renderer process when there are no handlers, or no handlers at the relevant location.  The scroll-blocks-on API I'm working on extends this further to let you explicitly opt-out of this blocking without suppressing the touch events entirely (i.e. giving them the performance properties of PointerEvents in this regard).

[PhistucK]

MouseEvent.prototype.simulated = true should be sufficient for this problem.

☆PhistucK

[Rick Byers]

On Fri, Jan 16, 2015 at 12:28 PM, PhistucK <phis...@gmail.com> wrote:

MouseEvent.prototype.simulated = true should be sufficient for this problem.

It is not.  See https://docs.google.com/a/chromium.org/document/d/1-ZUtS3knhJP4RbWC74fUZbNp6cbytG6Wen7hewdCtdo/edit# and other threads on public-touchevents for discussion.  Additionally we can't achieve the performance benefits by simply filtering out the events in JS (eg. we still have to do hit-tests to get them to JS in the first place).

 

☆Phistu

[Rick Byers]

On Fri, Jan 16, 2015 at 11:17 AM, Patrick H. Lauke <re...@splintered.co.uk> wrote:

On 16/01/2015 16:14, Rick Byers wrote:

On Fri, Jan 16, 2015 at 11:01 AM, Patrick H. Lauke
<re...@splintered.co.uk <mailto:re...@splintered.co.uk>> wrote:

    Quickfire gut reaction (beyond "dammit, do you want to remove all
    interesting topics from my presentation/workshop?")


Heh heh - I guess it's kinda the point of  the TECG to make input
handling so easy/obvious that it puts you out of a job <grin>.

The contortions you guys go through just so you can stick with your "no, Pointer Events have problems" ("no we won't admit it's purely because of Apple's reluctance") attitude is admirable nonetheless ;)

How's this for clarity: If Mobile Safari ships support for pointer events, than I promise that we'll ship them in chromium as well.

Ok, now that that's out of the way - let's go back to talking about reality ;-)

[Matt Gaunt]

The end goal of my comment is: what does a sane API look like - touch events result from touch, mouse events result from mouse, nothing more, nothing less.

I agree doing compat events is great for older sites and we shouldn't try and guess if the site is "old" or not - it's too late in the game for that to be using anything like the viewport meta tag.

So how about we just move to having an api to disable compat mouse events? I would love this and by default, no behavior change. Regarding libraries - this is SUPER easy to make optional and as a result developers would have to enable this option (or update a lib to use it) at which point you'd start to see these issues BUT it's an additional change that breaks, nothing breaks today with the addition of this kind of API.

Regarding the - this encourages touch only: it doesn't. This actually makes it easier to support touch and mouse events simultaneously. We know people write code that checks for the existence of touch and disables mouse as a result and the reason behind, in part, is because of the compat events confuse matters, you can't easily have both events registered.

I'm not opposed to having the simulated style api on mouse events either - but that can also work with this API.

[Patrick H. Lauke]

On 16/01/2015 18:08, Matt Gaunt wrote:
> The end goal of my comment is: what does a sane API look like - touch
> events result from touch, mouse events result from mouse, nothing more,
> nothing less.
>
> I agree doing compat events is great for older sites and we shouldn't
> try and guess if the site is "old" or not - it's too late in the game
> for that to be using anything like the viewport meta tag.

DOCTYPE switching, perhaps? I jest, of course...

> So how about we just move to having an api to disable compat mouse
> events? I would love this and by default, no behavior change.

My preference would definitely be a new method, a la
e.preventMouseCompatibilityEvents() (or something a bit more terse, but
I'd rather be explicit enough to avoid confusion).

Only question is: as "click" is currently handled as a compatibility
event as well in the TE model, would the above also kill "click"? I
guess it wouldn't be a deal-breaker if it did, mind, and would keep
things straightforward enough (i.e. wouldn't change the definition of
"compatibility event" - after we specify that definition in the TE
Errata/v.2). In fact, if it did, that would also make the naive

var clickEvent = ('ontouchstart' in window ? 'touchend' : 'click');
blah.addEventListener(clickEvent, function() { ... }, false);

pattern redundant, and instead allow for BOTH touchend and click to be
added as event listeners, since the click could be explicitly suppressed.

foo.addEventListener('touchstart', function(e) {
e.MouseCompatibilityEvents();
...
}, false);

/* doubled-up event listeners */

foo.addEventListener('touchend', someFunction, false);
foo.addEventListener('click', someFunction, false);

This is conceptually very similar to some of the current advice (for iOS
and old Android WebKit at least, where no other method to remove the
300ms delay is available - see
http://patrickhlauke.github.io/touch/tests/results/#suppressing-300ms-delay)

foo.addEventListener('touchstart', function(e) {
e.preventDefault();
}, false);

/* doubled-up event listeners */

foo.addEventListener('touchend', someFunction, false);
foo.addEventListener('click', someFunction, false);

but without the side effect that preventDefault() has of also killing
scrolling, zooming, etc.

Anyway, sorry, rambling away...but hopefully makes some kind of sense.

[Rick Byers]

On Fri, Jan 16, 2015 at 4:04 PM, Patrick H. Lauke <re...@splintered.co.uk> wrote:

On 16/01/2015 18:08, Matt Gaunt wrote:

The end goal of my comment is: what does a sane API look like - touch
events result from touch, mouse events result from mouse, nothing more,
nothing less.

I agree doing compat events is great for older sites and we shouldn't
try and guess if the site is "old" or not - it's too late in the game
for that to be using anything like the viewport meta tag.

DOCTYPE switching, perhaps? I jest, of course...

So how about we just move to having an api to disable compat mouse
events? I would love this and by default, no behavior change.

My preference would definitely be a new method, a la e.preventMouseCompatibilityEvents() (or something a bit more terse, but I'd rather be explicit enough to avoid confusion).

Only question is: as "click" is currently handled as a compatibility event as well in the TE model, would the above also kill "click"?

Why do you say click is handled as a compatibility event?  I consider TE to be pretty similar to PE in the regard that "mouse*" events are for compat, but "click" supplies real semantics / value outside of compat (it's the "activate" or "tapGesture" event IMHO).  So personally if we had a method called "preventMouseCompatibilityEvents" I would NOT want it to effect "click".

 

I guess it wouldn't be a deal-breaker if it did, mind, and would keep things straightforward enough (i.e. wouldn't change the definition of "compatibility event" - after we specify that definition in the TE Errata/v.2). In fact, if it did, that would also make the naive 

var clickEvent =  ('ontouchstart' in window ? 'touchend' : 'click');
blah.addEventListener(clickEvent, function() { ... }, false);

Whoa - detecting a 'tap' is more involved than that in practice. You don't want your 'click' function to fire for every swipe, or fire multiple times after a multi-touch, right?

[Olli Pettay]

On 01/16/2015 06:14 PM, Rick Byers wrote:
> On Fri, Jan 16, 2015 at 11:01 AM, Patrick H. Lauke <re...@splintered.co.uk <mailto:re...@splintered.co.uk>> wrote:
>
> Quickfire gut reaction (beyond "dammit, do you want to remove all interesting topics from my presentation/workshop?")
>
>
> Heh heh - I guess it's kinda the point of the TECG to make input handling so easy/obvious that it puts you out of a job <grin>.
>

> On 16/01/2015 15:51, Rick Byers wrote:
>
> I believe lots of websites still rely on these events for compat,
>
>

> Which I believe is their entire "raison d'etre"...I'm sure it was a pragmatic solution taken by Apple at the time.
>
>
> Absolutely.

>
> 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?
>
>

> Two issues:
>
> - the events are there for compat with "legacy" content...which is usually unlikely to be updated now. So default should be to have the compat
> events still enabled by default, no?
>
>
> Yes, we can't go breaking the web. But we might be able to identify some subset where we could disable these events by default with little/no
> negative impact, but I guess that's unlikely. It can be useful to try some (non-shipping-by-default) experiments though to help us learn about the
> patterns of dependence here. Eg. I'd hope that the vast majority of sites with mobile viewports aren't relying on these today (but even then it's
> probably not anywhere near the ~99.98% of page views we'd likely need to even consider making this the default).
>
> - how do you programmatically define/recognise (with heuristics) a "modern scenario"? I'd be weary of automagic behavior here. Also, there may be
> scenarios where even modern (recently built) sites somehow make use of mouse compat events (don't ask me why...) somehow (even if just to simplify
> their handling of stuff, e.g. setting a flag on touch* event, but leaving the actual functionality to happen on mouse* event).
>
> Perhaps looking on load if any mouse listeners have been registered may be an initial approach (though it would fall foul of any listeners that
> are dynamically added at a later date).
>
>
> Yeah this is hard and probably impossible to come up with something we could actually ship to people. I don't think we should use presence of
> handlers as a signal - that can result in 'heisenbugs' where the act of adding an event handler changes the behavior of what you're trying to observe :-(
>
> So for now I think the most productive discussion is "in the long-run, do we think you should be able to write responsive web apps that don't fire
> these events, and if so what might an API to opt-out of them look like?".

Not sure what this has to do with responsive web apps. The compatibility events aren't' dispatched often and shouldn't cause any real world
performance issues (you need to do hit testing for click anyway, and in the most common case you could just cache the hit testing result and use that
for all the events).

I'm not a fan of changing this already odd model to even more strange when in some mode some events are dispatched but in some other mode they aren't
- without seeing some data that adding the new mode has significant help in UX of web pages (and this after making sure browser engines don't do silly
things with hit testing).


-Olli

>
> 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
>
>

> P
> --
> Patrick H. Lauke
>

> www.splintered.co.uk <http://www.splintered.co.uk> | https://github.com/__patrickhlauke <https://github.com/patrickhlauke>
> http://flickr.com/photos/__redux/ <http://flickr.com/photos/redux/> | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>

[Sangwhan Moon]

I'm with Olli on this one. Also, with some browsers implementing the changed model and some not (I can't see Safari or Presto changing at this point), I can't see how this would make life significantly easier for content authors.

--

Sangwhan Moon [Opera Software ASA]
Software Engineer | Tokyo, Japan

[Patrick H. Lauke]

On 18/01/2015 05:36, Sangwhan Moon wrote:

> I'm with Olli on this one. Also, with some browsers implementing the
> changed model and some not (I can't see Safari or Presto changing at
> this point), I can't see how this would make life significantly easier
> for content authors.

I admit that even I can only see a marginal advantage here, particularly
as to solve "double click handling" authors will still need the "this
event is a compat event / the result of a touch event" API discussed
separately, so they'll still need to modify their code regardless (at
which point they can add a "is this a derived event" check to their
mouse* handler functions too - unless we ARE saying that's a performance
hit).

Not trolling, but wondering: with regards to Presto, are there any
browsers on touch devices still using Presto? Old Android devices not
capable of upgrading to Chromium-based Opera? (I'm guessing older
desktop installations, as well as TVs and STBs, but these don't have
touch events, so would be unaffected by this proposed change)

As for Safari, I'm working on the assumption that Apple - since they
steadfastly refuse to consider Pointer Events - have tacitly /
off-the-record agreed to try and make Touch Events environment more
powerful instead by implementing (or at least considering) these sorts
of changes...(or rather, that the chances are much greater for them to
implement an extension to TE rather than PE).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke

[Sangwhan Moon]

On Sun, Jan 18, 2015 at 6:58 PM, Patrick H. Lauke <re...@splintered.co.uk> wrote:

On 18/01/2015 05:36, Sangwhan Moon wrote:

I'm with Olli on this one. Also, with some browsers implementing the
changed model and some not (I can't see Safari or Presto changing at
this point), I can't see how this would make life significantly easier
for content authors.

I admit that even I can only see a marginal advantage here, particularly as to solve "double click handling" authors will still need the "this event is a compat event / the result of a touch event" API discussed separately, so they'll still need to modify their code regardless (at which point they can add a "is this a derived event" check to their mouse* handler functions too - unless we ARE saying that's a performance hit).

Not trolling, but wondering: with regards to Presto, are there any browsers on touch devices still using Presto? Old Android devices not capable of upgrading to Chromium-based Opera? (I'm guessing older desktop installations, as well as TVs and STBs, but these don't have touch events, so would be unaffected by this proposed change)

While disclosing the number isn't possible for obvious reasons, I just checked and yes, there is a notable amount of active installations on Android as of today. I don't know much about the other platforms though.

I'm even seeing quite a few people posting reviews today. (this is no secret, since the reviews are public)

As for Safari, I'm working on the assumption that Apple - since they steadfastly refuse to consider Pointer Events - have tacitly / off-the-record agreed to try and make Touch Events environment more powerful instead by implementing (or at least considering) these sorts of changes...(or rather, that the chances are much greater for them to implement an extension to TE rather than PE).

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

[Rick Byers]

Let me take a stab at summarizing this long thread:

1) There are lots of websites that depend on the compatibility mouse events fired on a tap, and it seems likely we'd be able to change that in any reasonable timeframe.  Therefore we're stuck firing these by default (and our ability to make dev's life simpler is therefore limited). 

2) If we did have an API for disabling compat events, folks agree that we'd still always want to fire "click" events.  But even those click events should have some way to identify them as being fired from touch events.  Therefore we want something like the firedFrom API regardless.

3) There isn't really a compelling performance argument for an up-front suppression rather than relying on 'firedFrom'.  Normally it should be possible to re-use hit-test results across multiple events.

Note that in chromium we've had some trouble with this as sites often depend, for example, on changes that occur in a mousemove or mousedown handler being reflected in the results of the hit-test for the mouseup handler.  But this just means the hit-test caching needs to be smart enough to get invalidated on DOM/style mutation.  Jacob, does IE do some sophisticated caching like that?

4) In composition scenarios, the decision whether to "fire" a compatibility event may need to be different for each event handler.  So in the limit you end up with an API that is virtually equivalent to this trivial polyfill over top of firedFrom (and therefore really only adds complexity):

Element.prototype.addEventListenerNoMouseCompat(type, handler, useCapture) {

  this.addEventListener(type, fuction(e) {

    if (!type.startswith("mouse") || !e.firedFrom("TouchEvent"))

      handler(e);

  }, useCapture);

};

5) Still it would be nice for apps to be able to opt-out from features whose only benefit is legacy compatibility (where such decisions can be made for an application as a whole).  We should be thinking about how the long-term future web platform can be as rational as possible (Matt's motivation I think).

I think Matt's goal is laudable, but in this case I don't see how we achieve it without risking adding more harm than good.  Maybe this should really be part of a larger discussions around patterns for the web platform here in general?  IE has a compat-hack system for opting specific sites into old behavior, but I don't think that's appropriate for major features - in part because it doesn't scale since most of the power is centralized with the browser implementer (vs. each web developer).   I believe both the Windows and Android platforms have gotten a lot of benefit out using the "target version" information embedded in an application to opt-out of legacy compat behavior (i.e. once you show you've tested your app against a particular platform version, the hacks necessary for compatibility with older versions are disabled).  The web platform unfortunately doesn't have a single linear version number that apps can target, but perhaps we could be working towards something with the same benefit.  Eg. I can imagine a mechanisms for apps to globally opt-out of specific legacy behaviors, and then some group that standardizes common names for groups of legacy behaviors (eg. maybe "html6" opts out of 100 agreed-upon legacy behaviors - extending what's been done with doctype).  If we had a general pattern like this to leverage, then I think the risk/benefit tradeoff would be very different.  But clearly now we're talking well outside the scope of this CG.

I'm happy to help drive a broader discussion on this problem in some more appropriate forum if folks are interested.  Thoughts?

So for now I think the most productive discussion is "in the long-run, do we think you should be able to write responsive web apps that don't fire
these events, and if so what might an API to opt-out of them look like?".

Not sure what this has to do with responsive web apps. The compatibility events aren't' dispatched often and shouldn't cause any real world performance issues (you need to do hit testing for click anyway, and in the most common case you could just cache the hit testing result and use that for all the events).

 Sorry, by "responsive" I meant "sites that automatically adapt for different form factors - i.e. phones vs. laptops".  If you're designing your site from scratch to work well with both touch and mouse input, then the compatibility mouse events provide no value to you.