Mac isn't affected, but Linux is, I don't know about windows.

If the code that runs in the input callback takes a long time, new input events can build up in the event loop faster than we can consume them. The issue is particularly severe when scrolling with the touch pad with WebRender if frame building takes a long time as hit-testing blocks on a synchronous message to the render backend.

It would nice if we had a way it collapse input events that have built up in the event loop when they do.

One way to do it could be to push input events into an array and schedule handling them in the event loop similarly to how we schedule composites on the compositor thread. this way when we get to handling input events we can collapse everything that is in the array. In most case we would have only one event to process and in the bad case we'd avoid accumulating.
This is what comes to mind but there are certainly other ways to avoid this problem.

Comment on attachment 9091727 [details]
Bug 1542056 - Allow hit-testing without synchronous messaging. r=botond, kats

Revision D45345 was moved to bug 1580178. Setting attachment 9091727 [details] to obsolete.