Well, that's definitely a shame. Please follow the Issue Reporting Guidelines and provide a minimal JSFiddle or JSBin containing a set of reproducible steps that can lead to the behaviour you described.

Looks like window.postMessage in chromium sometimes has random delays. The problem is it happens with about 10% chance on my project and i still havent found reliable way to reproduce it.

If that's the case, it may be a bug with chromium. Have you tried on a stable version of any other browser?

Delays reproduce in chromium based browsers(chrome, opera). There is no delays in firefox. Have not tried IE yet.

That's a starting point for a repro

I faced similar problem too in Windows 10 / Chrome 53.0.2785.116 m (64-bit).

rc6: https://jsfiddle.net/k6bgu2z6/4/
rc7: https://jsfiddle.net/v9q9L0hw/2/

In the rc6's example, yellow square don't move when scrolling container element.
In the rc7's one, yellow square swings vertically when scrolling.

1.0.27 has same problem.

Well, that reproduction is only part of my problem(small lag), sometimes delay gets bigger. But its still same problem.

Sigh, we may need to revert this...

The primary reason I changed the implementation is because MutationObserver (which is the original implementation) is buggy in iOS UIWebView >= 9.3.3 - it simply breaks after scrolling the page for a bit. However in iOS10 sniffing it apart from other environments like WKWebView and native iOS Safari is extremely tricky.

1.0.27 / 2.0.0-rc.7 uses a setImmediate shim using window.postMessage, which uses the macrotask queue instead of the microtask queue (used by MutationObserver). The difference being that macrotasks are queued after current browser rendering/IO jobs (e.g. repaint on scroll event) while microtasks are queued before that. This leads to the behavior seen in @wonderful-panda 's jsfiddles and the delays seen by @xelia (most likely associated with heavy repaints on scroll).

I guess we will have to revert to MutationObserver with more UIWebView sniffing...