Although in theory the problem is universal, in practice the problem only appears when the user is using touchpad-based scrolling; touch-based scrolling is typically unaffected.
But it’s all happening because you’re interacting with the scroll position in a way that is incorrect within the models of the platform, reading and writing the scroll position as though it were atomic and sequentially consistent when it’s not, so it could break in more situations at any time. It’s thus much better to avoid the technique and work in a way that is supported.
(I’ve decided to change the terms I’m using from synchrony to atomicity. For users familiar with that domain: the problem is essentially equivalent to the scroll position being atomics that are changed from another thread, but you’re doing a load and a store, probably with relaxed sequential consistency, rather than using an atomic swap operation, or a mutex lock over a non-atomic. There is no recourse while using this technique because the scroll position is not exposed as an atomic or something lockable.)
But it’s all happening because you’re interacting with the scroll position in a way that is incorrect within the models of the platform, reading and writing the scroll position as though it were atomic and sequentially consistent when it’s not, so it could break in more situations at any time. It’s thus much better to avoid the technique and work in a way that is supported.
(I’ve decided to change the terms I’m using from synchrony to atomicity. For users familiar with that domain: the problem is essentially equivalent to the scroll position being atomics that are changed from another thread, but you’re doing a load and a store, probably with relaxed sequential consistency, rather than using an atomic swap operation, or a mutex lock over a non-atomic. There is no recourse while using this technique because the scroll position is not exposed as an atomic or something lockable.)