Bug 149526
| Summary: | Wheel event triggered only once per touchpad touch | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michał Gołębiowski-Owczarek <m.goleb+bugzilla> |
| Component: | UI Events | Assignee: | Simon Fraser (smfr) <simon.fraser> |
| Status: | RESOLVED FIXED | ||
| Severity: | Critical | CC: | bdakin, berkaey, bfulgham, blanchette, gregor.adams, m, pierre.denis.vanduynslager, simon.fraser, webkit-bug-importer, webkit |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 10 | ||
| Hardware: | Mac | ||
| OS: | OS X 10.11 | ||
Michał Gołębiowski-Owczarek
Open http://output.jsbin.com/mimiqi/ in Safari 9 and scroll using a MacBook touchpad. The counter at the top left shows how many times the wheel event is fired. In all browsers except Safari 9 (i.e. Chrome, Firefox, **even Safari 8**) the event is fired once per animation frame. Safari 9 USUALLY fires it only once per touching the touchpad, although sometimes it switches into once-per-frame mode (scroll a little in various directions and you should see it).
This will break many interactions that depend on wheel happening in every animation frame to provide a custom scroll-like UI.
Note that I can't reproduce this new broken behavior on JSFiddle which may mean it doesn't happen in iframes (the test case is identical): http://jsfiddle.net/eoxzpqn5/
Is there any chance of this getting fixed in Safari 9? Seems pretty severe to me. :(
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Michał Gołębiowski-Owczarek
If this matters, I'm testing on a mid-2012 non-retina MacBook Pro. OS X 10.11 (15A282a).
Radar WebKit Bug Importer
<rdar://problem/22851046>
Berkay Sargin
same issue here, for my case custom-scrolling solution won't work in safari 9 it was working with safari 8.(and others)
Berkay Sargin
btw magic mouse is the same also.
Michał Gołębiowski-Owczarek
Has this been fixed? My test case seems to no longer be broken in Safari 9.1, at least I can't reproduce it anymore; I've changed the MacBook from the last time I tried the test case so I can't be sure it didn't change something.
Michał Gołębiowski-Owczarek
Sorry, false alarm, I tried on the wrong browser. The bug is still there. :(
Simon Fraser (smfr)
This happens because EventDispatcher::wheelEvent() sends the event to the scrolling tree, which claims to handle it (by doing fast scrolling), so we never end up in the event dispatching code.
What should really happen here is that we make the whole page be a slow event region.
Simon Fraser (smfr)
Ah, we have a correct non-fast scrollable region, but we return early from ScrollingTree::shouldHandleWheelEventSynchronously() because of latching logic.
Michał Gołębiowski-Owczarek
We had to add a note about this Safari bug to jquery-mousewheel because of multiple reports about it:
https://github.com/jquery/jquery-mousewheel/commit/18e3cc17657237220c4dbd68a3fe4f6abdbf7ef8
Please fix it, the jquery-mousewheel plugin is quite popular so a lot of people are affected.
I really wish issues like that were given higher priority.
Gregor Adams
The bug has not been fixed in Safari 10, probably not even addressed.
I think Apple should start working on this since it is a real showstopper.
Showstopper: "a feature is entirely broken and causes issues on many platforms"
blanchette
We are also running into this problem and it's certainly a show stopper bug for us.
The WebKit team NEEDS to address this, there isn't even anybody assigned to it.
This is clearly reproducible and is causing issues for many users, whats the deal?
Guido Bouman
Your best chance of gathering attention to this ticket is by everyone reporting a bug through Apple's official bug reporting program: https://bugreport.apple.com/
I've submitted one this morning.
Simon Fraser (smfr)
I fixed this in https://trac.webkit.org/changeset/261427/webkit