Thx for the contribution :) I had no idea about these inconsistencies with scrolling handling. I'll browse through it as soon as I'll have some time.

I just found this and can also comment it's the first thing I noticed. On a macbook trackpad under 10.8.3 the sensitivity is almost inverted, where the less I move my fingers the stronger the scrolling reaction.

Glad to hear there might be a solution

Can someone please give me the buffer output from here: http://jsfiddle.net/3J7f4/2/

for devices/browsers experiencing wrong scrolling speed in Sly?

This is a single swipe down, which on my macbook pro (2011) trackpad is a scroll down:

mousewheel : -36 : 0 : -12
mousewheel : -69 : 0 : -23
mousewheel : -62 : 0 : -62
mousewheel : -60 : 0 : -20
mousewheel : -27 : 0 : -9
mousewheel : -54 : 0 : -18
mousewheel : -123 : 0 : -41
mousewheel : -42 : 0 : -14
mousewheel : -18 : 0 : -6
mousewheel : -39 : 0 : -13
mousewheel : -54 : 0 : -18
mousewheel : -30 : 0 : -10
mousewheel : -15 : 0 : -5
mousewheel : -30 : 0 : -10
mousewheel : -27 : 0 : -9
mousewheel : -36 : 0 : -12
mousewheel : -21 : 0 : -7
mousewheel : -21 : 0 : -7
mousewheel : -9 : 0 : -3
mousewheel : -27 : 0 : -9
mousewheel : -18 : 0 : -6
mousewheel : -15 : 0 : -5
mousewheel : -21 : 0 : -7
mousewheel : -12 : 0 : -4
mousewheel : -6 : 0 : -2
mousewheel : -12 : 0 : -4
mousewheel : -9 : 0 : -3
mousewheel : -3 : 0 : -1
mousewheel : -12 : 0 : -4
mousewheel : -15 : 0 : -5

This is a swipe up

mousewheel : 69 : 0 : 23
mousewheel : 66 : 0 : 22
mousewheel : 60 : 0 : 20
mousewheel : 54 : 0 : 18
mousewheel : 54 : 0 : 18
mousewheel : 96 : 0 : 32
mousewheel : 42 : 0 : 14
mousewheel : 42 : 0 : 14
mousewheel : 39 : 0 : 13
mousewheel : 18 : 0 : 6
mousewheel : 33 : 0 : 11
mousewheel : 33 : 0 : 11
mousewheel : 30 : 0 : 10
mousewheel : 24 : 0 : 8
mousewheel : 24 : 0 : 8
mousewheel : 24 : 0 : 8
mousewheel : 21 : 0 : 7
mousewheel : 39 : 0 : 13
mousewheel : 18 : 0 : 6
mousewheel : 15 : 0 : 5
mousewheel : 15 : 0 : 5
mousewheel : 9 : 0 : 3
mousewheel : 12 : 0 : 4
mousewheel : 12 : 0 : 4
mousewheel : 12 : 0 : 4
mousewheel : 9 : 0 : 3
mousewheel : 12 : 0 : 4
mousewheel : 9 : 0 : 3
mousewheel : 6 : 0 : 2
mousewheel : 9 : 0 : 3

This is a very slow swipe down

mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -6 : 0 : -2
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1
mousewheel : -3 : 0 : -1

Can someone please test the new wheel delta normalization from commit above?

You need to grab the development version from src/sly.js

The new version still scrolls way too fast on a macbook trackpad in chrome, if I scroll only a bit on my touchpad I immediately reach the end of a 8k pixels page. The difficult part is that macbook trackpads accelerate when you scroll faster so you have to somehow detect that magic...

Some examples from your previous fiddle:

http://hastebin.com/lejaxijaka

Safari also behaves differently when scrolling:

http://hastebin.com/getakipenu

Sorry for spamming, but I'm noticing that the scrolling speed affects the speed of the animation and not the range of the scroll. When I scroll slowly it just slowly animates the scoll, but when I scroll quickly the animation speeds up but the range of the scroll stays about the same.

So ideally we should not only take the "scrollBy" into account but also the animation speed.

It was too fast in the first place? May have been useful to mention :)

Right now, I'm trying to understand how could your PR fix anything. The normalizeScrollSpeed function is a giant mess. Everything in it is basically negated by line:

d = Math.min(Math.max(d / 2, -1), 1);

Which forces the delta to be -1, or 1, making almost everything above that line irrelevant. After that, it divides this delta in half when Safari userAgent is detected, and returns the value. So if we are in safari, the returned value will be -0.5 or 0.5.

You than take this value, and if we are not in an item based navigation (i.e. when scroll is controlled by amount of pixels, not items), you use it to multiply the scrollBy option. That also leaves item based navigation scrolling the same.

The whole thing can be basically replaced by:

if (!itemNav && safari) {
    o.scrollBy /= 2;
}

Which hardly seems like a fix. And I'm definitely not doing userAgent sniffing.

Before the normalization attempt, Sly was scrolling the content by the same amount of pixels/items per one mousewheel event. The normalization took into consideration that one event might be a concatenation of multiple events, if they are triggered too fast. In which case, I'm multiplying the wheelDelta by number of events concatenated.

The normalization than scrolls by N times more pixels if it detects N events concatenated, which works as expected in most browsers that behave this way.

This obviously makes the matter in affected browsers even worse. If the base delta is 3, the wheelDelta of 450 is just ridiculous, and will result into scrolling by 150 * scrollBy.

You say that the default behavior of this browsers is: distance scrolled per scroll events fired is the same, but only the scroll speed/velocity changes (ref issue #29). This means that if we are interested only in scroll distance, we should ignore the wheelDelta altogether, which was the Sly behavior before the normalization attempt.

So right now, it seems that the issue is too high frequency of mousewheel events fired in affected browsers.

Someone correct me if I'm wrong :)

Oh, right. That normalizeScrollSpeed function is supposed to return the floating point between -1 and 1. But than it is just indirectly lowering the frequency of events. And also this can't be used in item based navigation, as you can't scroll by 0.3 item.

I'm going to close this PR and continue in a dedicated issue.