Created attachment 342750 [details] [diff] [review] patch which fixes the problem Right now if there are multiple MotionNotify events in the X event queue, they are all compressed to 1 (the newest), regardless whether or not they're contiguous in the queue. So, you can end up in situations where you have a queue that looks like this: MotionNotify (100, 200) => ButtonPress (100, 200) => ButtonRelease (100, 200) => MotionNotify (200, 200) and that gets compressed to: MotionNotify (200, 200) => ButtonPress (100, 200) => ButtonRelease (100, 200) Clearly that's broken. This is due to XCheckWindowEvent being used, instead of Peek+Next event. This usually won't be a problem, but it's definitely breaking our automated Moonlight testing using XTest, as that extension has the tendency to load up the client event queue. I've attached a patch which fixes our issue and has no negative impact on normal usage.
Created attachment 342751 [details] [diff] [review] doh, remove that printf.. [Checkin: Comment 8]
Comment on attachment 342751 [details] [diff] [review] doh, remove that printf.. [Checkin: Comment 8] Thanks man!
"firstname.lastname@example.org": Please, supply your real name(s), not your email address only.
huh, I thought bugzilla had my real name already... anyway, fixed.
(In reply to comment #3) > "email@example.com": Please, supply your real name(s), not your email address > only. Even so, please don't remove the checkin-needed keyword for reasons like this. Bugs get lost when you do that. :(
ack - wasn't aware i'd done that - sorry :)
(In reply to comment #6) > ack - wasn't aware i'd done that - sorry :) You didn't. I was talking to Serge. :)
Comment on attachment 342751 [details] [diff] [review] doh, remove that printf.. [Checkin: Comment 8] http://hg.mozilla.org/mozilla-central/rev/1ce7fddcb2ce
It looks like Stuart backed this out on the FENNEC_A1_BRANCH because it broke something: http://hg.mozilla.org/mozilla-central/rev/04cb6a409e9e
This should be backed out on trunk -- it's causing the fennec problems; need to figure out why (and why they're not being seen on the desktop).
("fennec problems" = mouse events are very laggy, you touch the screen and move the mouse, and the app responds only after a second or so delay, with the motion that you did)
I think the problems on fennec are probably due to the maemo gtk2 patches that unconditionally enable xinput events thus breaking this hack to do event compression since every motion event is followed by a device motion event. See bug 459780 for some more details. Perhaps the right way to fix this is using motion hints properly instead of emulating them poorly.
This, probably appropriately, wasn't backed out on m-c trunk.