| Summary: | Mouse wheel event not getting fired above certain element | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Laszlo <laszlo> | ||||
| Component: | UI Events | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Blocker | CC: | a_protyasha, ap, karlcow, simon.fraser, webkit-bug-importer | ||||
| Priority: | P2 | Keywords: | BrowserCompat, InRadar | ||||
| Version: | Other | ||||||
| Hardware: | Mac (Intel) | ||||||
| OS: | macOS 12 | ||||||
| URL: | https://smartslider3.com/fullsize/ | ||||||
| Attachments: |
|
||||||
|
Description
Laszlo
2023-05-10 04:26:44 PDT
I am not seeing the slider at the top of the page. 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.
Ah, I inteprested “slider” to be something like a range control. Will test again. 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. Are the events getting trapped by the scrollbar? Seems unlikely? Not getting close enough to it to activate. 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. 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. (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. |