[connor4312]

I'd hardly call this feature pointless. Scroll events, with cancellation support, have been a thing for well over a decade. This solves a very real problem of having to execute single-threaded application code that blocks scrolling. Particularly on mobile where resources are constrained and scrolling is smooth, this is a big problem.

Having developers hint to the browser that the event will not be cancelled solves it very simply. Far more simply and predictably than any kind of static analysis could.

[syberspace]

You seem to be misunderstanding my point. I'm definitely all for passive listeners. But I am very much against putting more workarounds for shitty developers directly into the browser.

[onion2k]

The change we're discussing here is something that the developer will need to explicitly add to their code;

By marking a touch or wheel listener as passive, the developer is promising the handler won't call preventDefault to disable scrolling.

Shitty developers who are lazy aren't likely to add that to their code if it 'works' without it. They are shitty after all. They won't care about a janky scroll on their webpage. Heck, they probably won't even test different ways of scrolling. Therefore it's fair to think this change is for awesome developers who test things and find that there's a problem, and need a way to fix it.

[syberspace]

yes, passive listeners are great. What I don't want in my browser is a static analyzing tool as the first comment I answered to suggested

[Piskvorrr]

Well...that's a bummer, as modern JS virtual machines used in browsers all use some sort of predictive code path model, and such static analysis is an integral part of this.