Description
Continuing from PR #57
Sly is scrolling the content by the same amount of pixels/items per one mousewheel event.
The problem number one is, that this event might be a concatenation of multiple events, if scrolling is happening too fast. This is reflected in event.wheelDelta property, which is multiplied by N, where N is the number of concatenated mousewheel events. At least that's how it works in like most of the world devices/browsers.
The detection of this concatenation is highly problematic, and at the moment I don't know about any 100% reliable way how to do that. Especially considering the inconsistency of this property across devices & browsers:
| evt.wheelDelta | evt.detail | |
|---|---|---|
| Safari v5/OS X | 120 | 0 |
| Safari v5/Win7 | 120 | 0 |
| Chrome v11b/OS X | 3 | 0 |
| Chrome v11b/Win7 | 120 | 0 |
| IE9/Win7 | 120 | undefined |
| Opera v11/OS X | 40 | -1 |
| Opera v11/Win7 | 120 | -3 |
| Firefox v4/OS X | undefined | -1 |
| Firefox v4/Win7 | undefined | -3 |
Old ilustrational table of one scroll event 'up'. Copied from this stakcowerflow question.
I've tried to detect the base wheelDelta by doing modulus of wheelDelta and [120, 40, 3], but that is obviously not 100% reliable. That beign said, it worked in 99% of cases, except Macbook Trackpads (and potentially other similar devices).
Mackbook trackpad's mousewheel event reporting is something else. The base is 3, but it can go as high as 450+. That is probably because in Mackbooks, this property doesn't report a value that specifies a destination, but rather the scroll velocity that should be used to control the scrolling animation speed.
This breaks everything.
I had to revert my attempt to normalize this, because modulus base detection on Macbook would just result into a ridiculous scroll distance per one event. And there is no way around it.
So currently, Sly will move the content by set number of pixels/items per event, disregarding event concatenation altogether. This is still a problem in Mackbooks, as the mousewheel event triggered by trackpads has a very high frequency, which results into a really fast scrolling speed, inconsistent with other devices using mouse wheel.
Currently, I don't see any reasonable fix for this, and userAgent sniffing is not an option.
I guess we have to wait until browsers will decide to implement a more standardized wheel event. Currently, only FF and IE9 support it.