Passive Events: tests

MDN documentation^[1] states that “browsers other than Internet Explorer and Safari” make some event listeners passive by default. In another project it seemed like it was Chrome and Safari that made those event listeners passive by default. I set this page up to test across browsers.

Test results: all modern browsers make these event listeners passive by default.

Here’s the side by side test, with the default setting on the left (page) and active event listener on the right (page). After attempting to scroll, scrolled tells us we could not prevent scrolling.

wheel events, desktop:

• Windows/Internet Explorer 11: cancelable=true, scrolled=false (active)
• Windows/Firefox 109: cancelable=true, scrolled=true (passive)
• Windows/Chrome 109: cancelable=false, scrolled=true (passive)
• Mac/Firefox 109: cancelable=true, scrolled=true (passive)
• Mac/Chrome 109: cancelable=false, scrolled=true (passive)
• Mac/Safari 16.3: cancelable=false, scrolled=true (passive)
• Linux/Firefox 109: cancelable=true, scrolled=true (passive)
• Linux/Chrome 109: cancelable=false, scrolled=true (passive)

touchstart and touchmove events:

• Android/Chrome 109: cancelable=false, scrolled=true (passive)
• Android/Firefox 109: cancelable=true, scrolled=true (passive)
• iOS 16.3/Safari: cancelable=false, scrolled=true (passive)

I did not have a machine where I can test touch events on desktop (Windows)

Desktop Chrome produced this error

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

Desktop Firefox produced this warning

Ignoring ‘preventDefault()’ call on event of type ‘wheel’ from a listener registered as ‘passive’.

Desktop Safari did not produce any error or warning.

https://developer.mozilla.org/en-US/docs/Web/API/Event/cancelable^[2] says

If the event is not cancelable, then its cancelable property will be false and the event listener cannot stop the event from occurring.

However it looks like Firefox currently sets cancelable to true even though the event is not cancelable. (bug^[3])