Bug 256582 - Mouse wheel event not getting fired above certain element
Summary: Mouse wheel event not getting fired above certain element
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: UI Events (show other bugs)
Version: Other
Hardware: Mac (Intel) macOS 12
: P2 Blocker
Assignee: Nobody
URL: https://smartslider3.com/fullsize/
Keywords: BrowserCompat, InRadar
Depends on:
Blocks:
 
Reported: 2023-05-10 04:26 PDT by Laszlo
Modified: 2023-08-25 11:19 PDT (History)
5 users (show)

See Also:


Attachments
A screenshot of the slider (606.85 KB, image/png)
2023-05-10 22:43 PDT, Laszlo
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laszlo 2023-05-10 04:26:44 PDT
OS and Browser information:
OS: macOS Monterey Version 12.6.5 (21G531)
Browser: Safari Version 16.4.1 (17615.1.26.101.10, 17615)

URL: https://smartslider3.com/fullsize/

Summary: If you visit the URL above you will find a slider at the top of the page, and if you try to scroll down on the area of the slider, it should make the slider advance to the next slide, but it won't always work in Safari.

Description: The codes responsible for moving the slides are running on the "wheel" event. The problem is that, the "wheel" event won't get fired in Safari. (It works fine in other browsers on the same Mac and also on Windows.)
As I noticed, when I modify CSS properties on some elements, the wheel event start working. ( Open the browser console, sometimes also fixes the problem but after the page is refreshed the problem occurs again. )

You can check whether the wheel event gets fired or not by doing the following:
1.) Open the browser console.
2.) Refresh the linked page: https://smartslider3.com/fullsize/ - just to avoid cases where the "wheel" event starts working because of console opening.
3.) Run this code in the console to track the events fired on the window: monitorEvents(window);
4.) Try to scroll on the area of the slider. Result: mouse wheel event won't get fired.
5.) Scroll down below the slider by using the scroll bar of the browser. Place the cursor over the white area below the slider ( as that is not the part of the slider ) and scroll. Result: mouse wheel event will be fired.
Comment 1 Simon Fraser (smfr) 2023-05-10 13:32:46 PDT
I am not seeing the slider at the top of the page.
Comment 2 Laszlo 2023-05-10 22:43:18 PDT
Created attachment 466313 [details]
A screenshot of the slider

I am attaching a screenshot of the slider and where you can find it in the DOM.
Comment 3 Simon Fraser (smfr) 2023-05-11 11:36:05 PDT
Ah, I inteprested “slider” to be something like a range control. Will test again.
Comment 4 Alexey Proskuryakov 2023-05-16 10:21:37 PDT
I certainly reproduce this with Safari 16.5 beta, using built-in trackpad:

1. Open https://smartslider3.com/fullsize/
2. Put the pointer over the three large dots at the right of the hero image
3. Try scrolling.

Results: the page scroll.
Chrome/Firefox results: the hero image changes to the next one.
Comment 5 Radar WebKit Bug Importer 2023-05-16 10:30:00 PDT
<rdar://problem/109411844>
Comment 6 Simon Fraser (smfr) 2023-05-16 15:37:18 PDT
Are the events getting trapped by the scrollbar?
Comment 7 Alexey Proskuryakov 2023-05-16 16:36:29 PDT
Seems unlikely? Not getting close enough to it to activate.
Comment 8 Laszlo 2023-05-25 02:50:27 PDT
The way this particular hero slider works is that, it prevents the "wheel" event with e.preventDefault() if the cursor is inside the area of the hero slider, except:
-you are on the first image and you scroll up
-or you are on the last image and you scroll down

This way scrolling on the area of the hero slider will make it rather advance to the next/previous slide instead of scrolling the page. And once you reach the first/last slide you can scroll the page itself.
Comment 9 Simon Fraser (smfr) 2023-08-21 17:58:21 PDT
This appears to be working correctly for me in STP 176.

266154@main fixed on issue in this area, but it seems that the problem existed in older builds.

What may be happening on slower devices is that we have a 50ms timeout, where we default to a "non-blocking" wheel event gesture (i.e. preventDefault stops working) if the content takes more than 50ms to respond to the first wheel event in the gesture.
Comment 10 Laszlo 2023-08-25 11:19:07 PDT
(In reply to Simon Fraser (smfr) from comment #9)
> This appears to be working correctly for me in STP 176.
> 
> 266154@main fixed on issue in this area, but it seems that the problem
> existed in older builds.
> 
> What may be happening on slower devices is that we have a 50ms timeout,
> where we default to a "non-blocking" wheel event gesture (i.e.
> preventDefault stops working) if the content takes more than 50ms to respond
> to the first wheel event in the gesture.

Thank you Simon!

Just checked it with Safari 16.6 (18615.3.12.11.2) using macOS Ventura ( 13.5.1 ) and the problem no longer occurs for me either.

I mark this as resolved.