GNOME Bugzilla – Bug 654831
Should reject future timestamp.
Last modified: 2011-07-20 17:51:18 UTC
Created attachment 192169 [details] [review] reject all future timestamps. Currently Mutter accept future timestamp and eliminate these invalid timestamps through sanity_check_timestamps(). However, this will lead window-list order corrupted while pressing Alt-Tab in gnome-shell. One noticeable example of xclients sending future timestamp is the XIM Module in gtk2. Currently, if user use XIM input method (such as fcitx) in a gtk2 application, gnome-shell will unable to switch back to this application in Alt-Tab view. There's video for this (by wengxt@gmail.com). http://blip.tv/play/AYLGhmAC This patch will reject all future timestamps, as far as I tested, it works good.
Have you investigated why the application/input method is creating bogus timestamps? I'm not happy about eating a round-trip to the X server on each application keystroke. (We're discussing stopping using the user timestamp for the application list order - that's a bit of an app. If an application sends a future timestamp, it would still cause problems for focus stealing prevention, but basically, the app has to stop sending bogus timestamps!)
Yes, I'm trying to hack into the gtk2 xim module as well as the xim protocol currently. That's going to take some time though. It's not totally Mutter's fault, nevertheless, this circumstance actually happened -- a broken xclient screw up the whole AltTab view. I believe it's better to reject it at WM level for security/robustness concern.
(In reply to comment #2) > Yes, I'm trying to hack into the gtk2 xim module as well as the xim protocol > currently. That's going to take some time though. > > It's not totally Mutter's fault, nevertheless, this circumstance actually > happened -- a broken xclient screw up the whole AltTab view. I believe it's > better to reject it at WM level for security/robustness concern. I'm not following. It's possible that XIM doesn't propagate timestamps correctly (though that would suprise me, since it's old school.) But if it doesn't, that still shouldn't lead to timestamps in the *future*.
I took a whole day hacking into gtk's source code, and found 1. Before calling XNextEvent() for queuing next event, gtk (both 2 and 3) forgot to memset(&xevent, 0, sizeof(XEvent)). This could cause the timestamp incredibly large. 2. Even if I did memset(), the returning event of XNextEvent() still have a fixed timestamp (from process start to exit) which it's not related to current time at all! Sometimes it's in the future, and sometimes it's in the past. I also investigate into IMdkit, I don't think it's sending message to the xclient with a timestamp. (It's sending a XClientMessageEvent, which doesn't have a timestamp at all.) So I suspect all of these weird behavior could be a bug of xorg, and I've already submitted at https://bugs.freedesktop.org/show_bug.cgi?id=39367 . Hmm...Am I on the right track of solving this problem? ...
Pretty sure that you should trace through fcitx and figure out what's going wrong there; I don't think there's any X.org component to this.