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.
> 
> thanks,
> -natevw

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.

dave
([email protected])



_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to