[syberspace]

I don't think I said people write shitty code on purpose, I'll have to go back and read my own comment to make sure though.

You might find that it is even a better option to do _more_ testing and debugging as opposed to cramming yet another pointless feature into already bloated browsers. And as a sibling to my previous comment mentioned: this is ripe with "unpredictability and interoperability issues"

Maybe create a `static js analysis` browser extension for developers to aide them in their endeavours to stop writing shitty code, but don't force that down everybody's throat.

[Piskvorrr]

Well, okay, great. Let's assume that I do write perfect code to run inside the webpage (which is what I strive for, and there are tools that help me with that; your radical new idea for JS static analysis tool has been implemented for years, and I'm actively using it). Great. And then the code needs to cooperate with multiple ad network codes, third-party plugins, all while working around browser-based bugs (oh, and did I tell you that there are various browsers, each with its own set of quirks?).

So, yes, I am trying my hardest not to write shitty code, and to make it resilient - but no: it doesn't help nearly as much as your original comment suggests it would, because there are numerous forces beyond my control affecting the result. Worse, some behaviors that are inconvenient to me are seen as desirable by the respective library/browser/OS makers ("you say bloat, I say essential feature"), so even if all the parties involved up and down the stack were producing 100% shit-free code, the result of their interactions could still be shitty.

As for the automated-under-the-hood-fixes inside browsers - yeah, that would be great if there wasn't a need for those, or if they didn't exist at all (even though I'm aware that their existence enables inflationary expectations in JS developers). I'd also like a pony while we're in wishing-land.

TL;DR: No, handwaving away complex and leaky abstraction stacks doesn't work.

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