Violation: non-passive event listener

[nemanjacosovic]

preact.esm.js:235 [Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952

[MaxPower15]

I have also noticed this, though it seems tough to deal with because there are legitimate cases for both passive and active handlers. As far as I know, the pattern to deal with the useCapture argument was to append Capture to the prop name, like onTouchStartCapture.

https://github.com/developit/preact/blob/33fc697ac11762a1cb6e71e9847670d047af7ce5/src/dom/index.js#L66-L73

It's probably possible to extend that concept to accept more boolean options, but I think that could get hairy as more are added--and what if there's a future option that isn't boolean?

To make this extensible, the only thing I can think of at the moment is to allow a new form of the prop that can accept more arguments than a singular callback. For example, in jsx...

<div onTouchStart={[this.onTouchStart, { capture: true, passive: true }]} />

Just an idea.

[developit]

@MaxPower15 I recall there was talk of a syntax like that going into React too. Another issue with boolean flags like onClickPassive is that they can't really be combined.
In terms of the example you listed, I actually really like that since it would be an extremely small addition to preact itself - if handler has a pop property (is an array), take handler[0] and use handler[1] as options. Only issue I see is that those same options would need to be passed to removeEventListener, even if they changed in the JSX.

[MaxPower15]

Well, one thing we could do, since onTouchStart can can only support one binding by virtue of no-duplicate-keys, would be to store the listener options with the function itself. Like eventProxy.onTouchStart1ListenerOptions = { capture: true, passive: true}. Then, if you have the function to unlisten, you're guaranteed to have the options it was bound with.

The downside/weirdness to that solution is: what if you want multiple listeners with different options? Seems like a super edge case, but maybe that's the case where I'd support a special suffix on the key that says "this is onTouchStart but a different version." Like:

<div
  onTouchStart1={[this.onTouchStart1, { capture: true, passive: true }]}
  onTouchStart2={[this.onTouchStart2, { capture: false, passive: true }]}
  onTouchStart3={[this.onTouchStart3, { capture: false, passive: false }]}
/>

That could be an interesting way generally to support multiple bindings for a single event type IMO.
But I think I'm getting off topic. 🙃

Anyway, I guess for compatibility you'd need to wait for React proper to make a decision about how they want to handle this, right? Any idea where that discussion is taking place?

[developit]

React's decision on this would be an important factor, but we can also experiment.

[Haroenv]

This issue is a duplicate of #428, and thus is better discussed there. If the number of open issues should be limited, this one can be closed

[marvinhagemeister]

Good call! I'll close this one in favor of #428 👍