Chrome for mac doesn't seem to like +/- 1px scrollTo

[paulhenrich]

Thanks for the handy library. I'm using it in conjunction with Dragula.

I was having some issues getting it to work with the target element as window (also with other configurations), and I decided to go check it in Safari. It worked. But not in Chrome. (Version 51.0.2704.29 beta (64-bit) for Mac).

Perplexed I dropped in breakpoints and saw that the window.pageYOffset was never incrementing. Somehow, surprisingly, it does increment if the base increment in on('move') is 3px or more.

My caller (I reduced pixels from my desired speed to compensate for the increased increment in move):

      autoScroll([window],
        margin: 30,
        pixels: 50,
        scrollWhenOutside: true,
        autoScroll: function() { return this.down; })

My adjustment to your library.

    this.point.on('move', function(el, rect){

        if(!el) return;
        if(!self.autoScroll()) return;
        if(!self.scrollWhenOutside && this.outside(el)) return;

        if(self.point.y < rect.top + self.margin){
            autoScrollV(el, -3, rect);
        }else if(self.point.y > rect.bottom - self.margin){
            autoScrollV(el, 3, rect);
        }

        if(self.point.x < rect.left + self.margin){
            autoScrollH(el, -3, rect);
        }else if(self.point.x > rect.right - self.margin){
            autoScrollH(el, 3, rect);
        }
    });

I'm on a non-retina Mac, so I don't expect any weird effects from pixel size, but my front-end fu is a little weak. Curious if anyone else has seen this and if it is worth digging into more.

[paulhenrich]

I'll dig into this a little tomorrow... I'm clearly missing something because at the console I can do window.scrollTo(0,window.pageYOffset+1) repeatedly and it works.

[hollowdoor]

Wow! I don't know. I will check soon to see if the same happens on my machine (regular pc Linux) though it could be a platform dependent problem.

Looking around on the internet I see lots of people have had problems with scrolling in Chrome. Mostly with the jquery scrollTo plugin. Some say Chrome is too fast. Others say it sets the offset too late after load. There was even one that pointed out the css overflow:hidden was the problem.

It's hard to say if getting pageYOffset, or setting with scrollTo is the problem.

It is also strange that you can still use window.scrollTo manually.

Other possible properties to use to get scroll offset are:

• document.documentElement.scrollTop
• document.body.scrollTop;

which can also be used as setters.

If there isn't a way to get scrollTo to work barring an actual Chrome bug I might try those other properties. I'm hoping not because I'd rather keep the scrollTo.

The problem could also be the pointer position, or dimensions not updating quickly enough for some reason. Extra pixels movement could allow a late pointer update to work.

[hollowdoor]

@paulhenrich I have tested it with Chromium on my machine. Using window works fine. I tested with my preferred options, and with the options you provided. Both work for me.

Since I don't have a mac, or the version of Chrome you're using I don't think I can help you with testing.

My specs are: Chromium version 49.0.2623.108 (Developer Build) Ubuntu 16.04 (64-bit).

My Chromium install is likely the latest, and probably has parity with the latest Chrome.

Probably the only best fix right now is an option for distance in the constructor to allow control over step distance on scroll. I'd prefer to not do this, but if the problem persists there might not be another option.

I will wait for a little while to add the option. Anyone else out there with an install of Chrome on mac that can help?

[hollowdoor]

@paulhenrich Can you run chrome://version/ in your url bar in your browser and post your chrome version here just in case?

[paulhenrich]

@hollowdoor makes sense to wait to add the option. I have had much time to try to dig more. My modification fixed it for my case and I feel comfortable using a fork.

Here's chrome://version

Google Chrome   51.0.2704.29 (Official Build) beta (64-bit)
Revision    d7a063c1fedf1f6ccb6eb9f50a9028bd742652d7-refs/branch-heads/2704@{#260}
OS  Mac OS X 
Blink   537.36 (@d7a063c1fedf1f6ccb6eb9f50a9028bd742652d7)
JavaScript  V8 5.1.281.18

[hollowdoor]

Thank you. I would like to wait a couple weeks to see if another person confirms this issue. We'll see if we can get more information about this from them. If no new information is presented I will add the option.

If you want you can try this method here: http://www.initcode.info/javascript_window_scrollto_alternative in the top answer.

That's a solution to a different problem from this issue, but I would like to see what happens if the scrollTo for window is replaced by a function from another object.

[hollowdoor]

I replaced the dependency to pointer-point with something else. Just letting you know. This might effect this particular bug.

[hollowdoor]

I've updated dom-autoscroller to version 2. If you can please update to version 2 to check to see if this issue is fixed.