Touch listeners defaulting to passive

[RByers]

Now that we have an API for passive event listeners, chromium wants to experiment with sometimes defaulting listeners into the passive state (in order to get results like this). If we can succeed in making some breaking changes for this, then we'll work with the TECG to explore changes to the TouchEvents spec.

Note that most browsers already have a form of intervention here in terms of a timeout. But this timeout does not follow most of the intervention guidelines and is in some ways the worst of both worlds. The hope here is that we can eliminate the need for such timeouts by replacing it with something that is both more rational/predictable for developers and provides a better user experience.

We only have a skeleton of a concrete proposal so far, but are collecting metrics from the wild to evaluate the tradeoffs of some possible proposals. Chrome 52 includes a flag allows users/developers to opt-in to a couple different modes of passive-by-default touch listeners.

EDIT 2/12/17: See #35 and this post for details of a specific intervention now shipping in Chrome 56. Updated to reflect shift in thinking from "forced" to just "default" (but overridable).

[RByers]

/cc @tdresser @dtapuska who are working on the engineering in chromium for this.

[RByers]

/cc @tdresser @dtapuska who are working on the engineering in chromium for this.

[RByers]

Note that we're thinking that this will start by applying only to cases where passive isn't specified like: addEventListener("touchstart", handler). That would then behave differently from addEventListener("touchstart", handler, {passive:false}). But this would be more of a migration strategy / hint than behavior we'd expect to keep long term (i.e. if CNN made their touch listener passive:false for some reason without fixing the jank, we'd still want to intervene on the user's behalf). So I don't think that distinction would ever really belong in the DOM spec. /cc @annevk @smaug---- @jacobrossi, thoughts?

[RByers]

Note that we're thinking that this will start by applying only to cases where passive isn't specified like: addEventListener("touchstart", handler). That would then behave differently from addEventListener("touchstart", handler, {passive:false}). But this would be more of a migration strategy / hint than behavior we'd expect to keep long term (i.e. if CNN made their touch listener passive:false for some reason without fixing the jank, we'd still want to intervene on the user's behalf). So I don't think that distinction would ever really belong in the DOM spec. /cc @annevk @smaug---- @jacobrossi, thoughts?

[smaug----]

If we start doing something like this, then it isn't clear to me at all anymore why we'd need 'passive'.
Especially given that there is touch-action and such.

[smaug----]

If we start doing something like this, then it isn't clear to me at all anymore why we'd need 'passive'.
Especially given that there is touch-action and such.

[RByers]

Interventions are primarily about improving the user experience at the expense of some developer rationality. A core part of the guidelines is that if developers follow best practices, they will never be impacted by an intervention. This lets us generate warnings / metrics around intervention triggering and drive them down as a thing to avoid. We can't do any of that without an explicit API where developers can opt-in in a rational manor to passive behavior.

[RByers]

Interventions are primarily about improving the user experience at the expense of some developer rationality. A core part of the guidelines is that if developers follow best practices, they will never be impacted by an intervention. This lets us generate warnings / metrics around intervention triggering and drive them down as a thing to avoid. We can't do any of that without an explicit API where developers can opt-in in a rational manor to passive behavior.

[RByers]

Quick update:

• The most promising change here seems to be to treat touch listeners on window, document, document.documentElement and document.body as passive by default (spec issue).
• Chrome has shipped the above behavior to 50% of dev-channel users and saw a 50% reduction in scroll start time at the 95th and 99th percentiles, without any reports of substantial breakage.

[RByers]

Quick update:

• The most promising change here seems to be to treat touch listeners on window, document, document.documentElement and document.body as passive by default (spec issue).
• Chrome has shipped the above behavior to 50% of dev-channel users and saw a 50% reduction in scroll start time at the 95th and 99th percentiles, without any reports of substantial breakage.

[smaug----]

Have you considered other options here, since this kind of change would make the platform less coherent internally and would add yet more special cases to the already complicated platform?
Like, a browser could have a "performance hint console" to tell to the web developers that whatever they are doing is probably slowing down ux and what they could do instead is and if they want to keep the existing behavior but don't see the warning again do .

I'm rather worried that if we end up adding more and more "interventions", we end up polluting the platform with tons of small hacks and inconsistencies, and such things tend to beat us later, when designing new APIs or spec'ing how the platform works.

[smaug----]

Have you considered other options here, since this kind of change would make the platform less coherent internally and would add yet more special cases to the already complicated platform?
Like, a browser could have a "performance hint console" to tell to the web developers that whatever they are doing is probably slowing down ux and what they could do instead is and if they want to keep the existing behavior but don't see the warning again do .

I'm rather worried that if we end up adding more and more "interventions", we end up polluting the platform with tons of small hacks and inconsistencies, and such things tend to beat us later, when designing new APIs or spec'ing how the platform works.

[RByers]

Yeah I'm worried about this too. We've long had devtools features highlighting scroll performance problems, and in general we've found they're helpful for developers motivated around perf, but when our goal is to improve the 95th percentile latency for users they're nearly useless (developers looking at perf in devtools are generally well below the 95th percentile, it's the sites where nobody is even measuring that matter most to the 95th percentile).

Long term ideally I think we'd aim to make touch events universally passive by default (basically the same way pointer events are, but with an opt-out if you really want it). That, I think, would be clean / rational from a web developers perspective. WDYT? Of course we'd need some transition path over many years to avoid breaking the web too badly in order to get there.

[RByers]

Yeah I'm worried about this too. We've long had devtools features highlighting scroll performance problems, and in general we've found they're helpful for developers motivated around perf, but when our goal is to improve the 95th percentile latency for users they're nearly useless (developers looking at perf in devtools are generally well below the 95th percentile, it's the sites where nobody is even measuring that matter most to the 95th percentile).

Long term ideally I think we'd aim to make touch events universally passive by default (basically the same way pointer events are, but with an opt-out if you really want it). That, I think, would be clean / rational from a web developers perspective. WDYT? Of course we'd need some transition path over many years to avoid breaking the web too badly in order to get there.

[rjgotten]

it's the sites where nobody is even measuring that matter most to the 95th percentile.

And your solution is adding hacks to the browser that affect every website everywhere and which can and do (note the referenced PhotoSwipe issue) suddenly break previously perfectly valid code which is intercepting touch events at the document level for anything as basic as page-wide drag&drop.

Here's a suggestion: put these hijinks behind a switch that devs can turn off with a <meta content="back-the-hell-off"/> tag, so there is an escape hatch until third-party libraries can catch up.

[rjgotten]

it's the sites where nobody is even measuring that matter most to the 95th percentile.

And your solution is adding hacks to the browser that affect every website everywhere and which can and do (note the referenced PhotoSwipe issue) suddenly break previously perfectly valid code which is intercepting touch events at the document level for anything as basic as page-wide drag&drop.

Here's a suggestion: put these hijinks behind a switch that devs can turn off with a <meta content="back-the-hell-off"/> tag, so there is an escape hatch until third-party libraries can catch up.

[smaug----]

The idea here is that web sites could explicitly use non-passive listeners by passing the right kind of dictionary to addEventListener.
But I agree, this kind of changes are a bit web dev hostile, which is why I was wondering if other mechanisms have been investigated to improve the ux of pages. Sounds like no.

[smaug----]

The idea here is that web sites could explicitly use non-passive listeners by passing the right kind of dictionary to addEventListener.
But I agree, this kind of changes are a bit web dev hostile, which is why I was wondering if other mechanisms have been investigated to improve the ux of pages. Sounds like no.

[dtapuska]

The PhotoSwipe code is setup to use PointerEvents but they are using the proprietary detection mechanism so when Chrome ships pointer events (M55) and FireFox does later this year it wouldn't take advantage of them.

meta tags are difficult for libraries to override set. So the escape hatch here is to provide a fully defined value. But really in this case it should be switched to use pointer events as it would be more efficient.

[dtapuska]

The PhotoSwipe code is setup to use PointerEvents but they are using the proprietary detection mechanism so when Chrome ships pointer events (M55) and FireFox does later this year it wouldn't take advantage of them.

meta tags are difficult for libraries to override set. So the escape hatch here is to provide a fully defined value. But really in this case it should be switched to use pointer events as it would be more efficient.

[RByers]

And your solution is adding hacks to the browser that affect every website everywhere and which can and do (note the referenced PhotoSwipe issue) suddenly break previously perfectly valid code which is intercepting touch events at the document level for anything as basic as page-wide drag&drop.

Yep, that's the nature of interventions: make the experience substantially better for a LARGE number of users at the cost of some small compat / developer pain cost. There's definitely a legitimate concern here about striking a good tradeoff, but in general the user experience has gotten so bad on the mobile web (putting the entire platform at such risk of economic collapse) that I don't think anyone involved really believes the right tradeoff is to land entirely on the side of developers over users. Our (Google web platform team's) thinking on that is mostly summarized here and yes it definitely includes that developers should usually have a way to opt-out (as they do in this case).

But note that if you're already following best practices (eg. making your site work correctly with touch on Microsoft Edge) then you'll already have a touch-action: none rule in such case and your site will continue to work fine. Even if you don't, it's likely your site will still work ok (eg. if it's really a full screen drag and drop then the page won't be scrollable). Specific counter examples appreciated, making the ideal tradeoff is challenging.

[RByers]

And your solution is adding hacks to the browser that affect every website everywhere and which can and do (note the referenced PhotoSwipe issue) suddenly break previously perfectly valid code which is intercepting touch events at the document level for anything as basic as page-wide drag&drop.

Yep, that's the nature of interventions: make the experience substantially better for a LARGE number of users at the cost of some small compat / developer pain cost. There's definitely a legitimate concern here about striking a good tradeoff, but in general the user experience has gotten so bad on the mobile web (putting the entire platform at such risk of economic collapse) that I don't think anyone involved really believes the right tradeoff is to land entirely on the side of developers over users. Our (Google web platform team's) thinking on that is mostly summarized here and yes it definitely includes that developers should usually have a way to opt-out (as they do in this case).

But note that if you're already following best practices (eg. making your site work correctly with touch on Microsoft Edge) then you'll already have a touch-action: none rule in such case and your site will continue to work fine. Even if you don't, it's likely your site will still work ok (eg. if it's really a full screen drag and drop then the page won't be scrollable). Specific counter examples appreciated, making the ideal tradeoff is challenging.

[RByers]

And just to make sure we're all clear on the benefit - we're talking about giving all users the experience on MANY major websites seen on the right of this video: https://www.youtube.com/watch?v=NPM6172J22g. Given the huge positive response that video has gotten from users, we're willing to accept a little bit of hacks / compat pain here.

[RByers]

And just to make sure we're all clear on the benefit - we're talking about giving all users the experience on MANY major websites seen on the right of this video: https://www.youtube.com/watch?v=NPM6172J22g. Given the huge positive response that video has gotten from users, we're willing to accept a little bit of hacks / compat pain here.

[rjgotten]

meta tags are difficult for libraries to override set.

Hence the libraries will have to fix their problems. A meta tag switch would be an escape hatch for developers depending on third-party libraries that have not been updated yet.

developers should usually have a way to opt-out (as they do in this case).

They're effectively stuck until all the libraries their project relies on, update to handle what is essentially a breaking change in their years of handling touch events.

Complex touch event scenarios are a [[censored]] nightmare hellscape. And now you're saddling devs with either switching to a different library (with its own potential weaknesses) or forcing them to dive into the guts of those libraries themselves to sort it out. If you call that a viable opt-out, you're mad.

---

Besides: do you know what the easiest way is to patch those issues? You override whatever abstraction for addEventListener the library uses to detect passive event listener support and include a passive:false that is hardoced for all events and which gives Chrome the finger. Road of least resistance. Road of least cost. And a road which ends in a status quo that is atleast known to work correctly, even if it performs worse.

Guess what solution companies that are already not interested in performance are going to use?

[rjgotten]

meta tags are difficult for libraries to override set.

Hence the libraries will have to fix their problems. A meta tag switch would be an escape hatch for developers depending on third-party libraries that have not been updated yet.

developers should usually have a way to opt-out (as they do in this case).

They're effectively stuck until all the libraries their project relies on, update to handle what is essentially a breaking change in their years of handling touch events.

Complex touch event scenarios are a [[censored]] nightmare hellscape. And now you're saddling devs with either switching to a different library (with its own potential weaknesses) or forcing them to dive into the guts of those libraries themselves to sort it out. If you call that a viable opt-out, you're mad.

---

Besides: do you know what the easiest way is to patch those issues? You override whatever abstraction for addEventListener the library uses to detect passive event listener support and include a passive:false that is hardoced for all events and which gives Chrome the finger. Road of least resistance. Road of least cost. And a road which ends in a status quo that is atleast known to work correctly, even if it performs worse.

Guess what solution companies that are already not interested in performance are going to use?

[tdresser]

In this case, developers don't need to wait for libraries to update, they can apply touch-action to the parts of their page that should prevent scrolling.

[tdresser]

In this case, developers don't need to wait for libraries to update, they can apply touch-action to the parts of their page that should prevent scrolling.

[rjgotten]

In this case, developers don't need to wait for libraries to update, they can apply touch-action to the parts of their page that should prevent scrolling.

In many complex interaction cases touch-action needs to be applied and unapplied dynamically, determined by the user's interaction state with various parts of a UI. That interaction state may well be under the control of a third-party library that is used to render part of the UI; or that implements an abstraction on top of touch events for complex user gestures that a UI requires.

So please explain again why you believe developers wouldn't need to wait for libraries to update, because there certainly are plenty of cases where they will...

[rjgotten]

In this case, developers don't need to wait for libraries to update, they can apply touch-action to the parts of their page that should prevent scrolling.

In many complex interaction cases touch-action needs to be applied and unapplied dynamically, determined by the user's interaction state with various parts of a UI. That interaction state may well be under the control of a third-party library that is used to render part of the UI; or that implements an abstraction on top of touch events for complex user gestures that a UI requires.

So please explain again why you believe developers wouldn't need to wait for libraries to update, because there certainly are plenty of cases where they will...

[maxkfranz]

And just to make sure we're all clear on the benefit - we're talking about giving all users the experience on MANY major websites seen on the right of this video: https://www.youtube.com/watch?v=NPM6172J22g. Given the huge positive response that video has gotten from users, we're willing to accept a little bit of hacks / compat pain here.

In my opinion, It should be the responsibility of those major websites to update their code to opt-in to new browsers features. If these websites are major, then they can certainly afford the dev resources to do so.

It's my understanding that a large part of the spirit of the web is that backwards compatibility is baked-in. Have a really old page from 1996? It should still work. Have a new webapp in 2017? That should work too.

This change can break pages and webapps that rely on touch events for the benefit of making sites with video, like CNN, faster. I don't think it's a fair trade-off to put speed over correctness --- regardless of how nice the speed is.

Please reconsider making this an opt-in feature rather than an opt-out one. The feature itself is a good idea, but I strongly disagree with changing well-established, default behaviour.

[maxkfranz]

And just to make sure we're all clear on the benefit - we're talking about giving all users the experience on MANY major websites seen on the right of this video: https://www.youtube.com/watch?v=NPM6172J22g. Given the huge positive response that video has gotten from users, we're willing to accept a little bit of hacks / compat pain here.

In my opinion, It should be the responsibility of those major websites to update their code to opt-in to new browsers features. If these websites are major, then they can certainly afford the dev resources to do so.

It's my understanding that a large part of the spirit of the web is that backwards compatibility is baked-in. Have a really old page from 1996? It should still work. Have a new webapp in 2017? That should work too.

This change can break pages and webapps that rely on touch events for the benefit of making sites with video, like CNN, faster. I don't think it's a fair trade-off to put speed over correctness --- regardless of how nice the speed is.

Please reconsider making this an opt-in feature rather than an opt-out one. The feature itself is a good idea, but I strongly disagree with changing well-established, default behaviour.

[RByers]

@maxkfranz that's an argument against all interventions, not just this one. There's legitimate debate to be had here, but let's keep it to #43 rather than spread across each individual intervention issue.

[RByers]

@maxkfranz that's an argument against all interventions, not just this one. There's legitimate debate to be had here, but let's keep it to #43 rather than spread across each individual intervention issue.

[ExtAnimal]

Why?

Why change the API like this?

It would be OK if availability of the object form of third argument was sniffable, but it's not. We can't know when to pass {passive: false, capture: useCapture} or just useCapture

So we can't prevent touchstart events from blurring by calling preventDefault.

(╯°□°）╯︵ ┻━┻

[ExtAnimal]

Why?

Why change the API like this?

It would be OK if availability of the object form of third argument was sniffable, but it's not. We can't know when to pass {passive: false, capture: useCapture} or just useCapture

So we can't prevent touchstart events from blurring by calling preventDefault.

(╯°□°）╯︵ ┻━┻

[tdresser]

You can feature detect, to determine whether to pass the third argument an object (though it's a bit clumsy).

See the EventListenerOptions explainer.

[tdresser]

You can feature detect, to determine whether to pass the third argument an object (though it's a bit clumsy).

See the EventListenerOptions explainer.

[RByers]

Though hopefully it's exceedingly rare to need to opt-out of passive touch listeners. touch-action is the simplest work-around in 99% of use cases.

Also the exact API design came from months of contentious standards debates - see here and the other links here for most of the history if you really want to know "why" the EventListenerOptions API has the design it does.

[RByers]

Though hopefully it's exceedingly rare to need to opt-out of passive touch listeners. touch-action is the simplest work-around in 99% of use cases.

Also the exact API design came from months of contentious standards debates - see here and the other links here for most of the history if you really want to know "why" the EventListenerOptions API has the design it does.

[maxkfranz]

@tdresser Yes, you can feature detect. But feature detection is useful only if you can change all affected code in your app.

If you're the only one using listeners, then you're OK. If you're using a lib that uses the addEventListener() function and it doesn't have a workaround specifically for this deviation from previous, standard behaviour, then you're really stuck.

@RByers To quote a previous comment about this: The main concern regarding Cytoscape is that the lib is used in many places, in both academia and commercial organisations, not all of which can easily update their code. Having support for passive events in Chrome is great but unfortunately, changing the default behaviour breaks our lib and many apps that depend on it.

I notice the following issue by @RByers in particular: WICG/EventListenerOptions#38. That seems much more sensible to me. Disabling preventDefault() (i.e. passive: true) for touch events should be opt-in, and a separate lib can facilitate making passive: true default just as you describe --- without breaking existing apps.

[maxkfranz]

@tdresser Yes, you can feature detect. But feature detection is useful only if you can change all affected code in your app.

If you're the only one using listeners, then you're OK. If you're using a lib that uses the addEventListener() function and it doesn't have a workaround specifically for this deviation from previous, standard behaviour, then you're really stuck.

@RByers To quote a previous comment about this: The main concern regarding Cytoscape is that the lib is used in many places, in both academia and commercial organisations, not all of which can easily update their code. Having support for passive events in Chrome is great but unfortunately, changing the default behaviour breaks our lib and many apps that depend on it.

I notice the following issue by @RByers in particular: WICG/EventListenerOptions#38. That seems much more sensible to me. Disabling preventDefault() (i.e. passive: true) for touch events should be opt-in, and a separate lib can facilitate making passive: true default just as you describe --- without breaking existing apps.

[rjgotten]

If you're using a lib that uses the addEventListener() function and it doesn't have a workaround specifically for this deviation from previous, standard behaviour, then you're really stuck.

I mentioned the same thing before. But for some reason some Google engineers seem to be deaf to this genuine software compatibility problem and live in a la-la land where developers have the luxury of being able and allowed to fork and patch any such library they're stuck using.

I don't terribly mind that passive would be the default behavior, but at the very least we need an easy one-shot method of turning this intervention off when compat problems arise.

[rjgotten]

If you're using a lib that uses the addEventListener() function and it doesn't have a workaround specifically for this deviation from previous, standard behaviour, then you're really stuck.

I mentioned the same thing before. But for some reason some Google engineers seem to be deaf to this genuine software compatibility problem and live in a la-la land where developers have the luxury of being able and allowed to fork and patch any such library they're stuck using.

I don't terribly mind that passive would be the default behavior, but at the very least we need an easy one-shot method of turning this intervention off when compat problems arise.

[maxkfranz]

I don't terribly mind that passive would be the default behavior, but at the very least we need an easy one-shot method of turning this intervention off when compat problems arise.

I think you have good intentions here: New apps you are making or apps you have direct control over could use a method like you propose.

My opinion is that's not enough, because apps or sites that won't be updated would still be broken. I don't think that's a fair trade-off.

[maxkfranz]

I don't terribly mind that passive would be the default behavior, but at the very least we need an easy one-shot method of turning this intervention off when compat problems arise.

I think you have good intentions here: New apps you are making or apps you have direct control over could use a method like you propose.

My opinion is that's not enough, because apps or sites that won't be updated would still be broken. I don't think that's a fair trade-off.

[rjgotten]

My opinion is that's not enough, because apps or sites that won't be updated would still be broken. I don't think that's a fair trade-off.

Then perhaps Google should themselves maintain a white-list of websites on which this intervention could be enabled and disable it for all others.

[rjgotten]

My opinion is that's not enough, because apps or sites that won't be updated would still be broken. I don't think that's a fair trade-off.

Then perhaps Google should themselves maintain a white-list of websites on which this intervention could be enabled and disable it for all others.

[tdresser]

Thanks for the feedback. Most of these comments apply to interventions in general. As rbyers@ commented above, there's legitimate debate to be had here, but let's keep it to #43 rather than spread general feedback about the interventions across each individual intervention issue.

[tdresser]

Thanks for the feedback. Most of these comments apply to interventions in general. As rbyers@ commented above, there's legitimate debate to be had here, but let's keep it to #43 rather than spread general feedback about the interventions across each individual intervention issue.

[rjgotten]

Please forgive me if I'm wrong, but in most scenarios (~80% of the top million sites use jQuery) there's absolutely no possible way for a developer to set passive to false without @Rycochet's poly-unfill, or something similar?

You're right; there is not. That's one of the major issues with this type of broken intervention that Google's engineers casually stepped over. Their proposed solution to that predicament amounts to a meme-tastic "patch all the libraries!"

[rjgotten]

Please forgive me if I'm wrong, but in most scenarios (~80% of the top million sites use jQuery) there's absolutely no possible way for a developer to set passive to false without @Rycochet's poly-unfill, or something similar?

You're right; there is not. That's one of the major issues with this type of broken intervention that Google's engineers casually stepped over. Their proposed solution to that predicament amounts to a meme-tastic "patch all the libraries!"

[dtapuska]

@simeydotme Can you elaborate why touch-action didn't work for your jquery plugins? Is the site externally visible?

[dtapuska]

@simeydotme Can you elaborate why touch-action didn't work for your jquery plugins? Is the site externally visible?

[rickbias]

@simeydotme it looks like Google engineers are trying to tell us to take control of our own javascript libraries. Stop relying on jQuery. Start to give a damn on user experience. Ahem, and taking care of the experience on slow android devices. As developers that taking the advantage of the platform born from the hard work of Google engineers, we got to pay our shares. It doesn't seem that they are going to revert this intervention anytime soon. Good luck.

[rickbias]

@simeydotme it looks like Google engineers are trying to tell us to take control of our own javascript libraries. Stop relying on jQuery. Start to give a damn on user experience. Ahem, and taking care of the experience on slow android devices. As developers that taking the advantage of the platform born from the hard work of Google engineers, we got to pay our shares. It doesn't seem that they are going to revert this intervention anytime soon. Good luck.

[dtapuska]

@rickbias @simeydotme touch-action is a CSS property and is very applicable to sites that are using jquery. You don't need a way to set passive: false provided you set the correct touch-action for the behaviour you want on the elements targeted. The question is whether touch-action describes the behaviour you want adequately. We know there are some deficiencies in the touch-action definition and want to be educated about the cases where touch-action doesn't work for them.

I hope that see my involvement here shows we do care about issues web developers face.

[dtapuska]

@rickbias @simeydotme touch-action is a CSS property and is very applicable to sites that are using jquery. You don't need a way to set passive: false provided you set the correct touch-action for the behaviour you want on the elements targeted. The question is whether touch-action describes the behaviour you want adequately. We know there are some deficiencies in the touch-action definition and want to be educated about the cases where touch-action doesn't work for them.

I hope that see my involvement here shows we do care about issues web developers face.

[simeydotme]

thanks @dtapuska for the response! :)
I will do my best to see if the css properties can help in my current scenarios. But I am not confident, And I really appreciate the time taken to feedback to individual comments. I can't imagine the amount of fires that need to be put out :P

I am not able to give immediate response about the viability of css touch properties, but upon reading https://developers.google.com/web/updates/2016/10/pointer-events quite carefully, its a little misleading as to what I really need to do. In my most pressing scenario I have a standard-ish carousel of product images that needs to block users vertically scrolling the page while it's being interacted with. That's default functionality which seems to be broken in chrome. Not only that; I am using native pinch-zoom to allow users to view the details of the images at will (on trackpad/screen), and finally I need to capture touchend/click to allow user to throw the image into a full-screen modal on larger viewports. But this is supposed to work flawlessly across device/screen. And of course I don't have the capability, or time, to remove libraries and write my own carousel.

Currently I haven't had a chance to properly investigate the chrome56 UX on touch-screen laptops, or android tablets. but while I have my devtools emulator open, I'm witnessing thousands of warnings in my console during normal use :( You'll understand aswell that I have this on internal testing servers right now, so not able to share.

I will come back as soon as possible with my results. And see if my findings can help others :) I didn't mean to ask for help/troubleshooting here, I wanted to express the thoughts of a slightly-privileged developer who builds things to get paid, and who's life is affected by things like this -- the feeling I had trouble describing in my previous comment was: In one way, it feels like all the corners that other developers and organisations have cut in perf/ux for their customers have been justified, and I got screwed for it. :/

[simeydotme]

thanks @dtapuska for the response! :)
I will do my best to see if the css properties can help in my current scenarios. But I am not confident, And I really appreciate the time taken to feedback to individual comments. I can't imagine the amount of fires that need to be put out :P

I am not able to give immediate response about the viability of css touch properties, but upon reading https://developers.google.com/web/updates/2016/10/pointer-events quite carefully, its a little misleading as to what I really need to do. In my most pressing scenario I have a standard-ish carousel of product images that needs to block users vertically scrolling the page while it's being interacted with. That's default functionality which seems to be broken in chrome. Not only that; I am using native pinch-zoom to allow users to view the details of the images at will (on trackpad/screen), and finally I need to capture touchend/click to allow user to throw the image into a full-screen modal on larger viewports. But this is supposed to work flawlessly across device/screen. And of course I don't have the capability, or time, to remove libraries and write my own carousel.

Currently I haven't had a chance to properly investigate the chrome56 UX on touch-screen laptops, or android tablets. but while I have my devtools emulator open, I'm witnessing thousands of warnings in my console during normal use :( You'll understand aswell that I have this on internal testing servers right now, so not able to share.

I will come back as soon as possible with my results. And see if my findings can help others :) I didn't mean to ask for help/troubleshooting here, I wanted to express the thoughts of a slightly-privileged developer who builds things to get paid, and who's life is affected by things like this -- the feeling I had trouble describing in my previous comment was: In one way, it feels like all the corners that other developers and organisations have cut in perf/ux for their customers have been justified, and I got screwed for it. :/

[marcoms]

Note that for over a year, the click delay has been essentially gone from the latest version of all major browsers, and for years before popular libraries like fastlick.js would disable themselves in Chrome/Firefox on mobile pages known not to have a click delay. Listening to touchend universally to avoid the legacy click delay is now pretty much an anti-pattern (as it causes a number of other problems).

Side point: True for the click event but there is still a discrepancy between touchstart and the CSS :hover state being activated - I made a library to get around it

[marcoms]

Note that for over a year, the click delay has been essentially gone from the latest version of all major browsers, and for years before popular libraries like fastlick.js would disable themselves in Chrome/Firefox on mobile pages known not to have a click delay. Listening to touchend universally to avoid the legacy click delay is now pretty much an anti-pattern (as it causes a number of other problems).

Side point: True for the click event but there is still a discrepancy between touchstart and the CSS :hover state being activated - I made a library to get around it

[rickbias]

I tried installing my custom pi-hole DNS, which blocks a lot of ads content (Google ads included), I can totally tell that it improves scrolling performance a lot. Sites load fast. Content is almost always immediately scrollable. Maybe chrome team should consider some kind of content blocker for chrome browser.

[rickbias]

I tried installing my custom pi-hole DNS, which blocks a lot of ads content (Google ads included), I can totally tell that it improves scrolling performance a lot. Sites load fast. Content is almost always immediately scrollable. Maybe chrome team should consider some kind of content blocker for chrome browser.

[emjayess]

Maybe people can ditch Chrome and start using Brave.

[emjayess]

Maybe people can ditch Chrome and start using Brave.

[rickbias]

I tried Brave, it is great. I don't mind paying for this browser if it can save my mobile data usage and improve my web browser experience a lot. I don't have to wait for ads to load.

[rickbias]

I tried Brave, it is great. I don't mind paying for this browser if it can save my mobile data usage and improve my web browser experience a lot. I don't have to wait for ads to load.

[Rycochet]

Looks like the people responsible for this bug are quietly hoping it'll go away, so pinging a reminder about how badly they screwed over countless thousands of sites instead of telling the few badly behaved sites to fix their crap...

[Rycochet]

Looks like the people responsible for this bug are quietly hoping it'll go away, so pinging a reminder about how badly they screwed over countless thousands of sites instead of telling the few badly behaved sites to fix their crap...

[RByers]

Sorry but our data indicates that the result was the opposite. We improved the performance on a vast swath of the mobile web while causing problems for a very small number of developers/sites and virtually no users (we've heard almost no complaints from users about broken sites). Our data suggests we made the right trade-off for the web platform as a whole and for Chrome as a product. I understand that your perspective is the opposite and I'm sorry about that - I really wish there was a way to make everyone happy, that's just not reality. The ultimate test will be what all browsers do in the long run (or at least all of those that care about scroll performance on low-end touch devices).

[RByers]

Sorry but our data indicates that the result was the opposite. We improved the performance on a vast swath of the mobile web while causing problems for a very small number of developers/sites and virtually no users (we've heard almost no complaints from users about broken sites). Our data suggests we made the right trade-off for the web platform as a whole and for Chrome as a product. I understand that your perspective is the opposite and I'm sorry about that - I really wish there was a way to make everyone happy, that's just not reality. The ultimate test will be what all browsers do in the long run (or at least all of those that care about scroll performance on low-end touch devices).

[Rycochet]

You've already proved that your data was far from complete, so that's always going to be a non-issue.

I really haven't got a clue where your idea that users would know to complain to you lot comes from - even developers need to jump through hoops to actually find this issue on here (go on, it's really easy to create a page that breaks because of this - give it to someone who is a normal user, then see how many years it takes them to find this).

Considering that I found one issue just this week where the Chrome devs contacted webmasters because of their sites behaving badly (rather than actually ending up with an intervention of some sort), and that this bug is still nowhere near being part of the standard - it's an issue that needs to keep being addressed until either it's fixed to match the standard, or the standard is fixed to match this...

[Rycochet]

You've already proved that your data was far from complete, so that's always going to be a non-issue.

I really haven't got a clue where your idea that users would know to complain to you lot comes from - even developers need to jump through hoops to actually find this issue on here (go on, it's really easy to create a page that breaks because of this - give it to someone who is a normal user, then see how many years it takes them to find this).

Considering that I found one issue just this week where the Chrome devs contacted webmasters because of their sites behaving badly (rather than actually ending up with an intervention of some sort), and that this bug is still nowhere near being part of the standard - it's an issue that needs to keep being addressed until either it's fixed to match the standard, or the standard is fixed to match this...

[RByers]

Note that I'm an editor of the standard here (Touch Events), I could probably change it to match Chrome now. But that's not the right focus, the right focus is implementation consensus. When another browser follows (and, based on the long conversations I've had with the relevant engineers, I do believe it's just a matter of "when") then we'll reflect that by updating the standard.

[RByers]

Note that I'm an editor of the standard here (Touch Events), I could probably change it to match Chrome now. But that's not the right focus, the right focus is implementation consensus. When another browser follows (and, based on the long conversations I've had with the relevant engineers, I do believe it's just a matter of "when") then we'll reflect that by updating the standard.

[Rycochet]

It's a breaking change, so why not get it into a proposed standards change so they've got something to work towards? It's still going to be 3+ years before coding without a polyfill to fix it will be standard (when relevant) simply because of how long we need to support older browsers, but it'll be a start...

[Rycochet]

It's a breaking change, so why not get it into a proposed standards change so they've got something to work towards? It's still going to be 3+ years before coding without a polyfill to fix it will be standard (when relevant) simply because of how long we need to support older browsers, but it'll be a start...

[RByers]

It is already a proposed standards change. Note that the issue was filed by the DOM expert at Mozilla, so it's not like the standards/browser community isn't talking seriously amongst ourselves about the right path forward here...

[RByers]

It is already a proposed standards change. Note that the issue was filed by the DOM expert at Mozilla, so it's not like the standards/browser community isn't talking seriously amongst ourselves about the right path forward here...

[Rycochet]

That's the same discussion as before, having had no further input nor discussion since March - saying that conversations with engineers are leading towards it is absolutely and completely useless - without public discussion nothing is going to change or move forward (or even reverting things - which would be a non-breaking change at least).

The arguments for this change are still built on broken data - not saying that it's a bad choice (though I'll class it as a bug until the specs change) and does need to be chased up on regularly until something changes - so hopefully this will push it a little :-)

[Rycochet]

That's the same discussion as before, having had no further input nor discussion since March - saying that conversations with engineers are leading towards it is absolutely and completely useless - without public discussion nothing is going to change or move forward (or even reverting things - which would be a non-breaking change at least).

The arguments for this change are still built on broken data - not saying that it's a bad choice (though I'll class it as a bug until the specs change) and does need to be chased up on regularly until something changes - so hopefully this will push it a little :-)

[simeydotme]

The Chrome Devtools Console should be renamed to the "Violation Dump"
QA teams questioning all the "violations", and I've noticed absolutely no improvement to my websites, or the websites I visit daily :/

[simeydotme]

The Chrome Devtools Console should be renamed to the "Violation Dump"
QA teams questioning all the "violations", and I've noticed absolutely no improvement to my websites, or the websites I visit daily :/

[Rycochet]

Just of note, as Edge still shows no signs of supporting the options parameter on addEventListener you still need to do browser / feature detection (and since IE will be around for many years that's unlikely to change this decade).

Typescript also only added support for the options parameter in 2.3.1 (Microsoft/TypeScript#14188) - so any code from before then would have had to override the argument type to use it.

[Rycochet]

Just of note, as Edge still shows no signs of supporting the options parameter on addEventListener you still need to do browser / feature detection (and since IE will be around for many years that's unlikely to change this decade).

Typescript also only added support for the options parameter in 2.3.1 (Microsoft/TypeScript#14188) - so any code from before then would have had to override the argument type to use it.

[patrickkettner]

Just of note, as Edge still shows no signs of supporting the options parameter on addEventListeneR

We've been shipping this in our insider build for a couple months. Should be in the next stable releaee

[patrickkettner]

Just of note, as Edge still shows no signs of supporting the options parameter on addEventListeneR

We've been shipping this in our insider build for a couple months. Should be in the next stable releaee

[Rycochet]

@patrickkettner Awesome! :-) Do you know (or can you say) if Edge is adding the passive default value for touch listeners?

[Rycochet]

@patrickkettner Awesome! :-) Do you know (or can you say) if Edge is adding the passive default value for touch listeners?

[patrickkettner]

Yep, you can follow along on the edge status dashboard

…

On Jun 19, 2017, at 4:21 PM, Rycochet ***@***.***> wrote: @patrickkettner Awesome! :-) Do you know (or can you say) if Edge is adding the passive default value for touch listeners? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[patrickkettner]

Yep, you can follow along on the edge status dashboard

…

On Jun 19, 2017, at 4:21 PM, Rycochet ***@***.***> wrote: @patrickkettner Awesome! :-) Do you know (or can you say) if Edge is adding the passive default value for touch listeners? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Rycochet]

In which case - anyone from the Mozilla / Firefox dev teams want to weigh in on here and have all the major browsers doing the same thing so this can get put into the standards and the whole issue closed?

(Just to say, that won't help the thousands of sites that have been broken by this and won't get updated, but will at least get things moving in the future, even if it is just overriding the option by default).

[Rycochet]

In which case - anyone from the Mozilla / Firefox dev teams want to weigh in on here and have all the major browsers doing the same thing so this can get put into the standards and the whole issue closed?

(Just to say, that won't help the thousands of sites that have been broken by this and won't get updated, but will at least get things moving in the future, even if it is just overriding the option by default).

[Rycochet]

I've noticed that the Verbose warning about passive listeners now turns up on all touch events in Chrome - which results in hundreds of thousands of (normally hidden) warnings before the tab crashes -

[Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive.

When the event specifically has {passive:false} added to it then it's a pretty good indication that is not possible. Adding specific CSS to say it won't scroll is not possible as the decision to scroll is made in Javascript on the event itself.

While I still hope that the standards change to fix this bug, these warnings are worse than useless with the sheer amount of spam appearing on even the simplest of web apps...

[Rycochet]

I've noticed that the Verbose warning about passive listeners now turns up on all touch events in Chrome - which results in hundreds of thousands of (normally hidden) warnings before the tab crashes -

[Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive.

When the event specifically has {passive:false} added to it then it's a pretty good indication that is not possible. Adding specific CSS to say it won't scroll is not possible as the decision to scroll is made in Javascript on the event itself.

While I still hope that the standards change to fix this bug, these warnings are worse than useless with the sheer amount of spam appearing on even the simplest of web apps...

[allMighto]

  <a
      href="tel:+xxxxxxxxxx"
    >CALL 6514 9729
  </a>

this code is printing this error on mobile view !

[Intervention] Unable to preventDefault inside passive event listener due to target being treated as passive. See https://www.chromestatus.com/features/5093566007214080

[allMighto]

  <a
      href="tel:+xxxxxxxxxx"
    >CALL 6514 9729
  </a>

this code is printing this error on mobile view !

[Intervention] Unable to preventDefault inside passive event listener due to target being treated as passive. See https://www.chromestatus.com/features/5093566007214080

[jfirebaugh]

Starting in iOS 11.3 beta, iOS Safari is shipping with a version of WebKit that defaults touchstart and touchmove event listeners on body, document and window to passive.

Unfortunately, WebKit does not support touch-action: none, so anyone who is relying on that to avoid this intervention will need to apply a second workaround, namely to bind the event with {passive: false} and use preventDefault.

https://bugs.webkit.org/show_bug.cgi?id=175346
https://bugs.webkit.org/show_bug.cgi?id=175869
https://bugs.webkit.org/show_bug.cgi?id=182521

[jfirebaugh]

Starting in iOS 11.3 beta, iOS Safari is shipping with a version of WebKit that defaults touchstart and touchmove event listeners on body, document and window to passive.

Unfortunately, WebKit does not support touch-action: none, so anyone who is relying on that to avoid this intervention will need to apply a second workaround, namely to bind the event with {passive: false} and use preventDefault.

https://bugs.webkit.org/show_bug.cgi?id=175346
https://bugs.webkit.org/show_bug.cgi?id=175869
https://bugs.webkit.org/show_bug.cgi?id=182521

[rjgotten]

@jfirebaugh

I've been waiting for something like this to happen for over a year now. That Apple would at one point copy Google's intervention was a given. That they'd do it without first implementing touch-action is hilarious, and also not entirely unexpected - given their track-record of launching broken or breaking web features.

Wonder what the "You just need to add touch-action:none to fix it"-crowd is going to say now.

[rjgotten]

@jfirebaugh

I've been waiting for something like this to happen for over a year now. That Apple would at one point copy Google's intervention was a given. That they'd do it without first implementing touch-action is hilarious, and also not entirely unexpected - given their track-record of launching broken or breaking web features.

Wonder what the "You just need to add touch-action:none to fix it"-crowd is going to say now.

[RByers]

Yeah this is unfortunate. I'm asking Apple to reconsider shipping the intervention here.

Wonder what the "You just need to add touch-action:none to fix it"-crowd is going to say now.

The "right" thing to say would be to show the ~20 lines of code necessary to properly feature detect touch-action and EventListenerOptions to set passive:false when the latter is supported without the former. But even I don't believe most people are likely to do that (or at least, those that are don't need my help showing how to do it). Despite the drawbacks, perhaps we should just encourage the simple one-line UserAgent check to ensure Safari always gets passive:false (regardless of whether they support touch-action in the future)?

[RByers]

Yeah this is unfortunate. I'm asking Apple to reconsider shipping the intervention here.

Wonder what the "You just need to add touch-action:none to fix it"-crowd is going to say now.

The "right" thing to say would be to show the ~20 lines of code necessary to properly feature detect touch-action and EventListenerOptions to set passive:false when the latter is supported without the former. But even I don't believe most people are likely to do that (or at least, those that are don't need my help showing how to do it). Despite the drawbacks, perhaps we should just encourage the simple one-line UserAgent check to ensure Safari always gets passive:false (regardless of whether they support touch-action in the future)?

[rjgotten]

@RByers

If you're talking a one-size-fits-all cure-all patch that can be injected from author-land, and which respects the intervention (rather than nuke it altogether by forcing passive:false as a universal default) ---

then I think you should detect support for the touch-action CSS property, rather than sniff for Safari's UA.

For any browsers that does not support touch-action, you'd want the sane default to be the 'oldskool' behavior.

Conversely any browser which does support touch-action can set its interactions up properly with that.
Well; usually anyway.

Luckily, for the really complicated edge cases where passive:false is absolutely necessary, such a polyfill would still patch addEventListener to universally accept EventListenerOptions arguments. It would just silently drop the passive flag and translate the capture flag to a boolean argument when EventListenerOptions are not supported. No harm done.

[rjgotten]

@RByers

If you're talking a one-size-fits-all cure-all patch that can be injected from author-land, and which respects the intervention (rather than nuke it altogether by forcing passive:false as a universal default) ---

then I think you should detect support for the touch-action CSS property, rather than sniff for Safari's UA.

For any browsers that does not support touch-action, you'd want the sane default to be the 'oldskool' behavior.

Conversely any browser which does support touch-action can set its interactions up properly with that.
Well; usually anyway.

Luckily, for the really complicated edge cases where passive:false is absolutely necessary, such a polyfill would still patch addEventListener to universally accept EventListenerOptions arguments. It would just silently drop the passive flag and translate the capture flag to a boolean argument when EventListenerOptions are not supported. No harm done.

[jfirebaugh]

But even I don't believe most people are likely to do that

From the perspective of a web developer responsible for a widely deployed library that has been broken twice now by this intervention: no, they aren't. The next version of Mapbox GL JS will be forcing passive: false and preventing default when it needs to, performance be damned. I expect other affected developers will do the same. This whole episode has been extremely frustrating from beginning to end, and I will do whatever it takes to prevent my software being broken again, even if that doesn't have ideal performance characteristics. Keeping my software actually functioning will always take precedence over performance, and the browser vendors have been quite inconsiderate of my needs, so I don't see any reason to bend over backwards with a bunch of feature detection, especially given that a previously-recommended solution has now been broken by a subsequent browser release.

@RByers: I know you have lots of metrics supposedly showing the advantages of this intervention. How are you measuring the costs? I see little or no consideration or discussion of costs in the metrics doc or blog post. However, between this issue, the blog post comments, this issue, and various other venues, there are probably hundreds of developers responding negatively to this intervention. Do you weigh that response in your decision at all? Is there any amount of developer anti-goodwill that would convince you that an intervention is a bad idea?

I've tried to keep this comment civil, but I have to admit it has been difficult. I'm really pissed at the decisions the Chrome and WebKit teams have made on this issue. I hope they reflect on the real difficulties and frustrations this intervention created for developers and end users, and reconsider making similar breaking changes to the web in the future.

[jfirebaugh]

But even I don't believe most people are likely to do that

From the perspective of a web developer responsible for a widely deployed library that has been broken twice now by this intervention: no, they aren't. The next version of Mapbox GL JS will be forcing passive: false and preventing default when it needs to, performance be damned. I expect other affected developers will do the same. This whole episode has been extremely frustrating from beginning to end, and I will do whatever it takes to prevent my software being broken again, even if that doesn't have ideal performance characteristics. Keeping my software actually functioning will always take precedence over performance, and the browser vendors have been quite inconsiderate of my needs, so I don't see any reason to bend over backwards with a bunch of feature detection, especially given that a previously-recommended solution has now been broken by a subsequent browser release.

@RByers: I know you have lots of metrics supposedly showing the advantages of this intervention. How are you measuring the costs? I see little or no consideration or discussion of costs in the metrics doc or blog post. However, between this issue, the blog post comments, this issue, and various other venues, there are probably hundreds of developers responding negatively to this intervention. Do you weigh that response in your decision at all? Is there any amount of developer anti-goodwill that would convince you that an intervention is a bad idea?

I've tried to keep this comment civil, but I have to admit it has been difficult. I'm really pissed at the decisions the Chrome and WebKit teams have made on this issue. I hope they reflect on the real difficulties and frustrations this intervention created for developers and end users, and reconsider making similar breaking changes to the web in the future.

[jfirebaugh]

PSA to fellow developers trying to clean up after this -- WebKit has several related bugs that you'll also need to work around:

• https://bugs.webkit.org/show_bug.cgi?id=184250
• https://bugs.webkit.org/show_bug.cgi?id=184251

[jfirebaugh]

PSA to fellow developers trying to clean up after this -- WebKit has several related bugs that you'll also need to work around:

• https://bugs.webkit.org/show_bug.cgi?id=184250
• https://bugs.webkit.org/show_bug.cgi?id=184251

[mike-marcacci]

Haha, I guess things really are cyclical :) perhaps Chrome should have multiple "rendering modes" – one that follows web standards, and another with potentially breaking interventions... and we can call the latter "quirks mode" for fun.

But seriously, it's not lost on me that a major reason for jQuery's ubiquity is that it unified the behavior of browsers, which had subtle differences in the way they approached features like event propagation.

[mike-marcacci]

Haha, I guess things really are cyclical :) perhaps Chrome should have multiple "rendering modes" – one that follows web standards, and another with potentially breaking interventions... and we can call the latter "quirks mode" for fun.

But seriously, it's not lost on me that a major reason for jQuery's ubiquity is that it unified the behavior of browsers, which had subtle differences in the way they approached features like event propagation.