Bug 244097 – "Wheel" events are not dispatched in iOS Safari when overscroll is disabled

• Status: NEW
• Component: Scrolling

[Jarod Gowgiel]

In iOS Safari, scrolling with a connected mouse does not work on sites that have disabled overscroll with some specific CSS rules. Specifically, `wheel` events are not dispatched to elements that have `overflow: hidden` or `overflow: none` when a mouse wheel is used on them. As noted in the bug linked below, hiding the address bar seems to "fix" this problem (by re-enabling overscroll, I think).

Preconditions that are necessary for this bug to happen:
* A <meta> tag like: `<meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=1.0, user-scalable=yes">`
* Specific `body` and `html` styling rules, with `width: 100%` and `height: 100%`

I've managed to generate a reproducible case at https://codepen.io/JarodG/pen/gOeZmpK?editors=1111. Note that, because of Codepen's handling of browser focus in the default editor, you'll need to follow a few setup steps if you don't have a "Pro" subscription:
* Fork the linked Codepen via the button in the bottom right toolbar.
* Open the forked Codepen in debug mode by replacing "pen" in the URL with "debug", or by using the "view" icon in the top right to switch to debug mode.

Notice: 
* Scrolling in any of the three boxes in debug mode in desktop Safari or Chrome causes `wheel` events to be properly dispatched.
* In a Simulator instance, or on an iPad, open the same debug view and connect a mouse (either via Bluetooth for a physical device, or via "Send Pointer to Device" in the simulator).
* Wheel events will only be dispatched to the first box, and not to either of the other boxes.

I believe this bug is related to https://bugs.webkit.org/show_bug.cgi?id=226080 - it may be the same issue, or it may not, since the link provided by [e-mail] has since gone dark and I can't compare the structure of that page to my reproducible case.

[e-mail], I'm adding you to the CC list here since you were mentioned in both the aforementioned bug, and https://bugs.webkit.org/show_bug.cgi?id=210071 which initially added `wheel` support for iOS.

[[e-mail]]

Hi, Isidor here from the VS Code team. Please let us know if there is any more details we can provide to help here. This is a long standing issue on our side https://github.com/microsoft/vscode/issues/106232

[[e-mail]]

You can use the following url instead of the previous one that has gone dark

https://vscode.dev/ from there you should be able to open a new empty file and notice that the mouse wheel is not working on the iPad.

And thanks a lot for looking into this. We really appreciate it.

[Jarod Gowgiel]

Hey Isidor - thanks for the link! We're running into an issue that's very similar to what VSCode is seeing over in Lucid Software's products (who I'm investigating this issue for). I think the same problem here is impacting VSCode in the browser as well - after some brief poking, it looks like the core editor is a custom implementation of a scrollable window, which uses `overflow: hidden`, and the same rules (including the <meta> tag) that cause the issue on our sites.

I can't think of any potential resolutions that we can take from the app side in either case, since it seems like both products rely on overscroll being disabled to improve the user experience. iOS Safari seems to be in violation of the W3 spec in this situation:

> A user agent MUST dispatch this event when a mouse wheel has been rotated around any axis, or when an equivalent input device (such as a mouse-ball, certain tablets or touchpads, etc.) has emulated such an action.

Keyword "MUST", and I think the bug here is that the event is, under certain conditions, not being dispatched at all.

[Jarod Gowgiel]

(In reply to Jarod Gowgiel from comment #3)
> Hey Isidor - thanks for the link! We're running into an issue that's very
> similar to what VSCode is seeing over in Lucid Software's products (who I'm
> investigating this issue for). I think the same problem here is impacting
> VSCode in the browser as well - after some brief poking, it looks like the
> core editor is a custom implementation of a scrollable window, which uses
> `overflow: hidden`, and the same rules (including the <meta> tag) that cause
> the issue on our sites.
> 
> I can't think of any potential resolutions that we can take from the app
> side in either case, since it seems like both products rely on overscroll
> being disabled to improve the user experience. iOS Safari seems to be in
> violation of the W3 spec in this situation:
> 
> > A user agent MUST dispatch this event when a mouse wheel has been rotated around any axis, or when an equivalent input device (such as a mouse-ball, certain tablets or touchpads, etc.) has emulated such an action.
> 
> Keyword "MUST", and I think the bug here is that the event is, under certain
> conditions, not being dispatched at all.

Quote taken from: https://www.w3.org/TR/uievents/#events-wheelevents

[Simon Fraser (smfr)]

This is being tracked internally via <rdar://88885351>.

[Radar WebKit Bug Importer]

<rdar://problem/99146306>