Specify addEventListener default passive hack for smoothscroll.js

[zcorpan]

So, Chromium and WebKit also implement this hack for smoothscroll.js:
https://bugs.chromium.org/p/chromium/issues/detail?id=501568
https://github.com/WebKit/WebKit/blob/dd956d5e74249681ddf904e0bbe401f308b65e0f/Source/WebCore/page/Quirks.cpp#L929-L946

As far as I can tell, Gecko does not. https://searchfox.org/mozilla-central/source/dom/events/EventListenerManager.cpp#1593 (and no search results for "ssc_wheel")

Should we put this in the spec?

The use counter is currently at ~0.01% of page views. But scrolling the page doesn't work at all without the hack.
https://chromestatus.com/metrics/feature/timeline/popularity/2020

Originally posted by @zcorpan in #365 (comment)

@domenic said

IMO we should put that hack in the spec, although it could perhaps be done separably since it's such a ... unique ... hack.

[annevk]

cc @smaug---- @EdgarChen

[zcorpan]

As noted in https://bugs.chromium.org/p/chromium/issues/detail?id=501568

firefox doesn't support 'mousewheel' events, only the standard 'wheel' events

Removing support for mousewheel events from Chromium and WebKit seems like a possible alternative solution here.

Chromium has use counters for only mousewheel, only wheel, or mousewheel+wheel listeners being invoked (implementation)

• WheelEvent ~5.35%
• MouseWheelEvent ~3.52%
• MouseWheelAndWheelEvent ~0.5%

Pretty high numbers... How come Firefox is able to not support the mousewheel event? I found this bug Consider supporting the legacy mousewheel event for interop which cites 3 webcompat.com issues, so they're taking some web compat hit by not supporting it.

In httparchive (total of 14,951,058 pages), there are 0 pages that hit the SmoothScrollJSInterventionActivated.

query

SELECT
  url
FROM
  `httparchive.pages.2022_06_09_mobile`
WHERE
  STRPOS(payload, r'SmoothScrollJSInterventionActivated') > 0

[zcorpan]

Hmm. I wonder if the SmoothScrollJSInterventionActivated is broken. The sample URLs chart in https://chromestatus.com/metrics/feature/timeline/popularity/2020 had a sudden cutoff in April 2019.

When looking for the pragma that would invoke it (("mousewheel", ssc_wheel)) in response_bodies, in the sample 10k dataset, I find 30 pages (0.3%, which is in line with the pre-April 2019 use counter numbers). Query results.

query

SELECT
  page,
  url
FROM
  `httparchive.sample_data.response_bodies_mobile_10k`
WHERE
  REGEXP_CONTAINS(body, r'\(\s*["\']mousewheel["\']\s*,\s*ssc_wheel\s*\)')

[zcorpan]

Ooooh, I finally get it. It's dead code! Since the intervention we're specifying for #365 already makes all mousewheel listeners on window passive (unless passive is specified), this hack does literally nothing. It can be removed.

[zcorpan]

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1337217

[RByers]

Oh, very cool! Sorry none of us put that together Simon! I was going to chime in here to say that back when I was looking into this I found a LOT of UA sniffing treating Firefox differently, and so I did expect that we'd need to specify this hack just for browsers claiming to be WebKit. But removing it is, of course, even better. Thanks for filing the issue!

[RByers]

Note that the problematic listener gets installed on body, not window. But chromium makes document and body listeners passive by default too, so I assume that's what's getting specced?

[zcorpan]

Yes, all of window, document, root element and "the body element"

[dtapuska]

Yes this hack forged the path for the larger intervention proving it was doable. I've removed it from blink.

[domenic]

Really great find Simon!! I guess we can close this issue now :).

[zcorpan]

Yep. I've also filed an issue for WebKit: https://bugs.webkit.org/show_bug.cgi?id=241782