Just created an other example with requestAnimationFrame calls and the issue is still the same !  Example: http://works.themepunch.com/k/a.html 

Hope to hear back from you very soon ! 

Able to reproduce the issue on Windows 7 using 51.0.2704.103, latest stable 51.0.2704.106, canary 53.0.2778.0 as per steps in comment #0.

Note:Working fine on Mac 10.11.5, Ubuntu 14.04.

This is regression issue broken in M-520.

Please find below bisect info:
Last good build:50.0.2638.0
First bad build:50.0.2639.0

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/6dff929a11a7b4c752f20afb9f2cf5033031582d..18f47f8161cbdbe7c69ce3f52ee52e4acfbf9024

From above CL, suspecting below:
https://chromium.googlesource.com/chromium/src/+/6ab38e4f06caa13bbcdfaa652109d114576c1cbe

sunnyps@Could you please look into this issue if it is related to your change, else feel free to assign it to an appropriate dev person.

Thanks,

tdresser@ Does this look like a duplicate of  bug 599152  or another issue that you've seen recently?

Great to hear that you know the reason of the issue. What is the plan after that ? Will the fix being introduced in the next updates as well ?  
/ We have tons of customers making our life being hell based on this issue./  

Also do you know if the same fix will come in all webkit browsers (safari and iOs just have the same issue. Only Firefox plays the game well right now)? 

Does setting passive:false for the handler avoid this problem?

Nope! Tested with both. {passive:false}  and {passive:true} has the same problem.

This is because we no longer block wheel scrolling on the main thread, which provides a significant performance improvement on many sites. Anything which looks worse with touchpad with this change would have already been broken with touch input.

Vsync aligned input will help with this, but it won't fix it entirely - if the main thread can't keep up, things could still get out of sync.

There has been some discussion of providing developers the ability to opt in to main thread scrolling, but it's been extremely contentious. 

Where are you actually running into this issue? It's possible there's a cleaner way to accomplish what you're going for that doesn't rely on thread synchronization.

We are the developer of the Slider Revolution Plugin which is used 2.000.000+ Websites all around the world already.  
Since our Products are Plugins, we are not allowed to overtake scroll behaviours of the Websites where our products included, and need to live with the surrounding Environment.

This is why we used to listen to the scroll and wheel events and redraw layers within our Slider based on current Scroll positions.  

The example i built for you shows quite well the situation http://works.themepunch.com/k/test.html  however here is one more complex example on our test environment: http://works.themepunch.com/revolution5/chrometest/

Even if the Slider in this example on the top of the Page, it could be added  in any container, jsut like the layers (menu layers in this case) which could be layers in any of the slides at any position. So we must provide a solution for our customers where the elements stay in one position during other element scrolled without jittering. 

Please note position:fixed would not help here since we need to respect the overflow hidden attribute of parent elements.  

I am open for any suggestion which could bring us further.  Issues was not know before version 50.0.2639.0

Thank you ! 

Krisztian from ThemePunch

Only one side note:  If you scroll by the Scroll Bar, it works perfect. So it happens only if page scrolled by the wheel. It must be a way to be able to update scroll positions based on the wheel and reflow things before the paint issues. Hope based on the examples above you will be able to help us !  Thanks again ! 

"position:fixed would not help here since we need to respect the overflow hidden attribute of parent elements."

Ah, that's the detail I was missing.

Ian, is there a reasonable way of getting position:fixed behavior that respects overflow:hidden without resorting to positioning via JS?

sorry, but the position:fixed can not be the solution in any way.  I made the example for you for better understanding with 100% parallax value.  This should work with any other parallax settings.  Means based on the scroll % based reposition the element.

Nowdays you will find millions of websites using this technic.  It is easy if you can prevent the default scrolling functions of the browsers, but as plugin developer we have no chance to do that, and we need to simple trust in the default events.   It must be some way to get / force interrupt the wheel process and be able to reset element attributes before repaint. 

Also imo the position:fixed is a very costable setting and would have other performance issues on many pages.

thank you ! 

If you only care about wheel, and not touch, you should be able to reposition the header on the wheel event, instead of the scroll event.

It has the same Bug ! Does not matter if i listen on wheel, mousewheel, scroll or DOMMousewheel, it has the same buggy jittering effect. Please look exactly in the code of the first example.   It is a bug in the browser.  Firefox works perfect, and earlier version of chrome works also perfect.

Thank you ! 

I made quick an example with mousewheel: http://works.themepunch.com/k/test-wheel.html
and with scroll: http://works.themepunch.com/k/test.html
and for both listening: http://works.themepunch.com/k/test-both.html

cheers.

Sorry, my mistake, of course using a wheel listener doesn't fix it.

Note that this doesn't work with touch in firefox either, you get the exact same jitter.


Other than a way to opt-in to main thread scrolling (or compositor worker), I'm not sure what we can do here. We've got some things in the pipeline that will improve this some, but because JS is running on a different thread than scrolling (which is true of every major browser, in some circumstances at least), this will never work completely.

I'll keep thinking on this though.

Is there a reason that you don't care about touch input? This has been broken with touch for ages.

Note that this behaves the same way in Microsoft Edge and Firefox nightly as in Chrome.

funny enough that in FireFox latest browser the Scroll on Mouse wheel acts beautifully and as written above older version of Chrome  (before 50.0.2638.0) works also great. 

We are interested in any solution you can provide us which allows us to position elements based on scroll positions after triggering touch or wheel without the jittering. Please advise ! 

Thank you ! 

Are you using Firefox nightly? 50.0a1 has the same issue you're seeing in Chrome (though it's a bit more subtle).

In general, there's no perfect solution at this point, but there are a few things you can do to make this better.

Do you really need to have overflow:hidden clip? The web doesn't deal well with position:fixed things with overflow:hidden. Folks could use css clip (https://developer.mozilla.org/en/docs/Web/CSS/clip) if they really need to clip the header, but that's a bit painful.

If you don't need overflow:hidden to clip, then you can use position:fixed.

To get parallax working, ideally you'd be able to use an approach like this (http://codepen.io/scottkellum/details/bHEcA) for pure CSS parallax, but it doesn't work with -webkit-overflow-scroll:touch.

If you need to behave correctly on iOS, then you could add a scroll event listener which offsets your position:fixed element. This would result in significantly less jumping around, but it won't be perfect.

There are some features on the way that will fix this, but right now, there's no perfect solution.

Thank you for your feedback ! 

Firefox 50.0a1 was in beta so i was ignoring it. But indeed in 50.x the issue exists also now. 

I think css clipping in complex contents with parallax effect are just a real pain at that point. I will go and try the css parallax tricks with different 3d depths, however that will lose quality on elements (make things blurry imo).

We just hope that the interrupt on wheel events will come back, or some other solution will be introduced which allows a smooth parallax effect calculated by javascript.  Please keep us informed if there are any news.

Thanks and greetings from the ThemePunch Developers ! 

Duping this bug on one of the possible solutions.

To stay up to date, I'd recommend also starring  crbug.com/347272 .

 Issue 622780  has been merged into this issue.

Sami, any idea why http://works.themepunch.com/k/test.html behaves so much worse than http://tdresser.github.io/sync-scroll-offset-test/?

Worse in what way? They seem pretty equal on my desktop -- especially if I change your example to try to keep the green box fixed to the viewport: http://output.jsbin.com/qoyucedaku/quiet

There's a visible amount of vertical jitter in both cases. Maybe both are a frame behind somehow?

Nevermind, you're right. The way my test was presented made me less likely to do long flings, which is what looks especially bad.

Sorry for the noise.

 Issue 619796  has been merged into this issue.