[webkit-dev] Mouse wheel event precision
hyatt at apple.com
Thu Jun 10 12:26:15 PDT 2010
On Jun 10, 2010, at 1:01 PM, Nathan Vander Wilt wrote:
> On Jun 9, 2010, at 3:51 PM, David Hyatt wrote:
>> On Jun 9, 2010, at 2:25 AM, Andy Estes wrote:
>>> On Jun 8, 2010, at 8:34 PM, Nathan Vander Wilt wrote:
>>>> What Safari 4 seemed to do was simply provide much greater precision, where scrolling half a line simply yielded about 20 units instead of being ignored. So the above code would yield integral deltas in browsers that only fired events in 3-line increments, but nice fractional deltas in WebKit.
>>> Some sites choose to completely ignore wheel deltas less than 120. On devices like trackpads where a slow but continuous scrolling gesture tends to result in a series of small, non-cumulative mousewheel events, the old behavior caused these gestures to be completely ignored. Yahoo! Mail was one such site where the small fractional values caused compatibility issues.
>>>> What Safari 5's WebKit does is turn one "line" into 4800 (!) units instead of 40.
>>> This could be plausible on a trackpad that scales the wheelDelta based on gesture velocity, although I'd expect a value of 120 for each tick of a conventional wheel mouse. As Peter said, if you have a test case where Safari disagrees with IE on Windows or Chrome on either platform, please file a bug and we'll investigate.
>> Just a guess, but we might have a regression when dealing with the continuous events generated by a MacBook trackpad.
> Thanks, David. I am testing this with my MacBook trackpad (and attached Magic Mouse) in Safari 5.
> The following demo will need some massaging to work in IE, but shows the problem. Scrolling down so "Line 4." is at the top of the page yields a deltaSum of -7200 (!). Interpreted according to MSDN documentation (http://msdn.microsoft.com/en-us/library/ms536951(VS.85).aspx) this would -60 "increments" (which IIRC are 3-line chunks each) and over seven thousand pixels according to Quirksmode's interpretation (http://www.quirksmode.org/dom/w3c_events.html, grep wheelDelta) of that property. Basically, the wheelDelta values are 60 times what they should be.
> On Safari 4, the deltaSum ends up at -120 as expected when scrolling down to "Line 4", although quite helpfully the sum can be reached gradually when the mouse has smooth scrolling. So I would concur that this a regression of some sort.
Having investigated the original bug and its fix that caused this regression, Safari 4's behavior was correct. The new behavior is broken. A tiny continuous event in Safari 4 correctly reported values that are smaller than one line delta, because that's exactly what was supposed to happen in terms of scrolling.
There are Web sites that depend on never scrolling less than 1 wheel delta line though. So what can we do to get the best of both worlds?
Well, the compatibility fix made all of the continuous deltas way larger than they should be, just to ensure that you never give a value smaller than 120. That was not the right thing to do.
If we can't evangelize the Web sites to fix their broken checks, then a better fix would be to just ensure that the minimum value of a wheel event is 120, without performing what amounts to "double multiplication" of the continuous event. This way we only inflate the continuous delta of the small scrolling gestures.
Even then, though, we lose some of the magic of continuous scrolling in that the small gestures aren't supposed to each result in single line movements. My top preference would be to evangelize the Web sites, but I would settle for applying the minimum of 1 wheel line (120) to continuous events. The current behavior is clearly wrong though and needs to be fixed.
(hyatt at apple.com)
More information about the webkit-dev