Safari 9 scroll is either 1 or -1

[drewbaker]

On Safari 9.0 (the latest), event.deltaY is either 1, or -1. It never goes any higher than that. So it's not consistent across browsers. On Chrome it works fine.

[dmethvin]

I don't have a Mac with iOS to try this on so others will need to provide some more detail. Did Safari make some kind of intentional change here? You're saying the event.deltaY value provided by the plugin is only 1 or -1, what are the raw values Safari is giving?

[drewbaker]

It's strange, because it works with the mouse wheel on my logitech mouse, but if I use the trackpad, it is just -1 or 1. Chrome and Firefox is fine.

Here is a screenshot of the entire event, when using trackpad:

And here it is when using mousewheel on external mouse:

[christian-thomas]

I've also got the same issue — All other browsers are fine, it's just the latest version of Safari that's giving 1/-1.

[dmethvin]

Put a breakpoint inside the plugin, on this line. What path does Safari 9 take, and what values does it calculate? How does that differ from Safari 8?

[christian-thomas]

So, from a brief bit of debugging, I amended lines 106-108:

    if ( 'detail'      in orgEvent ) { deltaY = orgEvent.detail * -1;console.log('detail - ' + deltaY);      }
    if ( 'wheelDelta'  in orgEvent ) { deltaY = orgEvent.wheelDelta;console.log('wheelDelta - ' + deltaY);      }
    if ( 'wheelDeltaY' in orgEvent ) { deltaY = orgEvent.wheelDeltaY;console.log('wheelDeltaY - ' + deltaY);      }

It looks like Safari 9 has some sort of debounce/throttling...

In Safari 8, depending how much I scroll, in a single mousewheel motion/scroll I'll get something like this:

    [Log] detail - 0
    [Log] wheelDelta - -60
    [Log] wheelDeltaY - -60
    [Log] detail - 0
    [Log] wheelDelta - -30
    [Log] wheelDeltaY - -30
    [Log] detail - 0
    [Log] wheelDelta - -90
    [Log] wheelDeltaY - -90

Same mousewheel motion/scroll in Safari 9, just:

    [Log] detail - 0
    [Log] wheelDelta - -3
    [Log] wheelDeltaY - -3

[Awea]

Hi there, any idea for a crappy work around for this one ?

[dmethvin]

It seems like it might be due to this Webkit bug reported by @mzgol : https://bugs.webkit.org/show_bug.cgi?id=149526

[kpettinga]

Experiencing the same issue over here as well. Is this something we'll have to wait for Safari or Webkit to fix?

[johndigital]

I'm not sure if this helps, but I've found a workaround for this. In my situation I'm trying to detect the deltaY when scrolling a non-scrollable page and use the value. Like everyone else I get a totally normal value in chrome and FF, but in Safari I just get 1 or -1 when using a magic mouse or trackpad:

It seems like this is being caused in part by the elastic scrolling that safari does. If the default scrolling behavior is disabled before using the deltaY value then the normal value comes through fine. The two easiest ways to achieve this:

1. Put overflow: hidden; on the body. This disables all scrolling
2. Add event.preventDefault(); before using event.deltaY. This will kill the default mousewheel behavior

Either of those fix it for me both using the mousewheel plugin and the underlying 'mousewheel' event. This obviously won't help if the default scrolling behavior needs to stay in tact, but worked great for my situation.

[dmethvin]

Nice detective work there @jrobson153! This leads me to think that there isn't a solution that the plugin can automatically implement to solve this because either of those has tradeoffs. If I knew of anyone at Apple I could escalate this to I would, but Apple isn't known for its responsiveness on browser issues. What would be the best place to document this, perhaps the README.md file?

[johndigital]

Yea, it could take them a while to catch up to this. I think a brief note in the Readme file would be helpful!

[dmethvin]

Did this get fixed in Safari 9.1?

[mgol]

My initial comment was wrong, the bug https://bugs.webkit.org/show_bug.cgi?id=149526 is still present in Safari 9.1.

EDIT: It's also still present in Safari Technology Preview & WebKit Nightly.

[sandrodz]

ah Safari... new IE never fails to deliver bogus issues, its been 2 years now this has not been fixed?

[jmzhang]

This might be a simpler workaround: do not scroll your content within body, wrap your stuff inside another div that has a fixed height (e.g. 100vh), and bind the scroll event listener on that div.

Here is a demo (cloned from the bug report and slightly modified): http://output.jsbin.com/suwatixaxu

One caveat though: this will break the minimal-ui on mobile safari as it depends on scrolling within the body.

[pixelass]

Here's another approach to fixing the issue: https://github.com/pixelass/onwheel-fix

drawbacks

• no elastic scroll in Safari 9 & 10 body.

advantages

• No css hacks
• No extra markup
• just init or destroy the fix when needed

It really just fixes the mousewheel bug where it occurs, by preventing the default event and reassigning the event.deltaY to element.scrollTop.

I tested it in Safari 9 & 10 with jQuery.mousewheel: Codepen Demo

The demo has nested elements with different overflows. The demo has a header that should scroll in and out on mousewheel. Look at the console to check the returned event.deltaX & event.deltaY

I did not write this to fix jQuery.mousewheel. This is a general fix that just turns out to work nicely with jQuery.mousewheel.

[pixelass]

Also.. the sad note is: It is still broken in Safari 10.

[solbreslin]

@pixelass I tried adding your fix, however I'm fairly new to javascript and not sure how to integrate it with the mousewheel code. The console tells me 'import' isn't recognised.
My code is something like this:

jQuery("#container").mousewheel(function(event,delta) {
                    this.scrollLeft -= (delta * 30);
                    event.preventDefault();
                });

Should I include the fix within that?

[pixelass]

@ovokuro you can try including it as a script

<script src="https://cdn.rawgit.com/pixelass/onwheel-fix/v0.3.3/dist/onwheel-fix.min.js"/>

I'm not sure about your setup.

import foo from 'foo' requires a build process that handles es6.

if you are loading jQuery and plugins in the head or body you should do the same for other scripts

after those scripts add a script tag with this content: (or load another script that contains this content)

var fixWheel = new FixWheel('wheel');
// or:   var fixWheel = new FixWheel('mousewheel');
fixWheel.init(document.body);

Hope this helps

[ultraarc]

In my computer, when I scroll the mousewheel, all broswers(chrome/IE11/firefox) will give either 1 or -1 for event.deltaY. Why people here can get different value for event.deltaY? Which is normal?

[solbreslin]

Thanks for your help @pixelass. Much appreciated.
Seems the problem I'm getting (erratic speeds) is only with a logitech mouse after updating to Sierra. Site worked fine on previous versions, and still works fine with apple mouse.

[pixelass]

@JustinHu1988 you should get different values:
[-1, 20, 108, -45, -10, 0] are all valid values.

You should check for other implementations or some example pages. If the issue only occurs on your own implementation there is most likely a bug in your code. You should create a demo which is not hosted in an iframe. This will help us understand what's going wrong.

@ovokuro

• which mouse model do you have (exact product name).
• Does the issue only occur in Safari or are other browsers affected?
• describe erratic speed
• does the issue occur without my plugin?

[ultraarc]

I've write a demo for this problem, and tested it in different computers, the event.deltaY is always 1 or -1. Maybe there are some problems in my code. This code in zip contains two online js files(jquery-1.7.2.min.js and jquery.mousewheel.min.js), they may not load smoothly, you can change it with your local file. Thanks for your help~
demo-for-mousewheel.zip

[solbreslin]

@pixelass

It was actually a Targus mouse: AMU3301EUM.
The site I've made scrolls horizontally. When I first used the mousewheel plugin I set the delta to 60 and it scrolled well on everything except trackpads on apple laptops - it was scrolling from one end of the page to the other instantly. I found a solution for this problem in the OSX inertia thread:

if (isMac) {
                this.scrollLeft -= (delta * 2);
            } else {
                this.scrollLeft -= (delta * 30);
            }

The site then seemed to scroll well on all browsers and devices. The designer I'm working with then updated her system to Sierra and found the scrolling really fast again, but some scrolls moved the page further than others. This was happening on Chrome and Safari, and only occurred with the Targus mouse. I then tried your plugin but it didn't seem to make a difference, so I've removed it.

Now, for some reason (maybe driver updates?), the scrolling has settled a bit with the Targus mouse but is still a bit jerky.

Let me know if you need more info.

[skiokko]

Still broken on Latest Safari (04/12/2017)
Incredible

[pixelass]

@skiokko I don't think the safari team considers this to be a bug.

[skiokko]

I agree. The bug is from the plugin not from Safari.

[skiokko]

I fixed it but use a simple js code:

 document.getElementById('main').addEventListener('wheel', function (event) {
                console.log(event.deltaY)
 });

The plugin is not required.

[mgol]

I agree. The bug is from the plugin not from Safari.

No, this is a Safari bug, see https://bugs.webkit.org/show_bug.cgi?id=149526. Your code is not adding a listener to the document but to a specific element so it's not hitting the issue.

[dmethvin]

See the Safari bug above for any updates on whether or when Safari will fix it. There is no way to fix it in the mousewheel plugin because Safari isn't giving us the information we need.