Setting proper timestamp for XEvent in Xwnmo (from forum message #65890 )

• Reporter: aonoto
• 소유자: aonoto
• Type: Patches
• Status: Open [Owner assigned]
• Component: (None)
• MileStone: 1.1.1-a024 (予定)リリース
• Priority: 4
• Severity: 4
• Resolution: Accepted
• File: None

Details Reply

フォーラム freewnn-users ML公開 [#65890] からの引用

zephyrus (zephyrus000jp) wrote in [forum: 65890]

/freewnn/FreeWnn/Xwnmo/xwnmo/callback.c We should set timestamp (0 means "current time" and seems a safe choice here) and preferably serial number as well.

 *** callback.c~ 2012-10-17 15:56:38.000000000 +0900
 --- callback.c  2012-10-17 16:00:31.000000000 +0900
 ***************
 *** 642,647 ****
 --- 642,649 ----
     ev.xkey.root = cur_x->root_pointer->root_window;
     ev.xkey.state = 0;
     ev.xkey.keycode = cur_x->max_keycode + 2;
 +   ev.xkey.time = 0;           /* FIXME */
 +   ev.xkey.serial = LastKnownRequestProcessed(dpy) /* FIXME */
     XSendEvent (dpy, ev.xkey.window, False, NoEventMask, &ev);
     XFlush (dpy);
   }

Thank you.

Ticket History (3/5 Histories)

2012-10-29 03:46 Updated by: aonoto

• New Ticket "Setting proper timestamp for XEvent in Xwnmo (from forum message #65890 )" created

2012-10-29 03:49 Updated by: aonoto

• Details Updated
• Resolution Update from None to Accepted

2012-10-29 04:01 Updated by: aonoto

댓글 올리기 Reply

We cannot cover xwnmo for now, but we try.

Can you explain more information about this change (e.g. pros (and cons if exists), example code I can refer to)?

2013-08-14 01:38 Updated by: aonoto

• Milestone Update from (None) to 1.1.1-a024 (予定)リリース

2013-11-25 11:15 Updated by: None

댓글 올리기 Reply

We cannot cover xwnmo for now, but we try. Can you explain more information about this change (e.g. pros (and cons if exists), example code I can refer to)?

This is zephyrus (sorry I am not logged in.)

I just realized there is this question posed to me (more than a year later...) I must have missed it somehow. Sorry about this lapse.

Basically, it seems that some software packages, most notably mozilla Firefox and Thunderbird which I use daily, seem to hold the timestamp of an event that is thrown to them internally. This is used for some internal processing. The problem is that if the timestamp is incorrect and far into the future, this bogus timestamp make Firefox and Thunderbird ignore the valid subsequent events such as for menu handling (showing pull down menu by cliking on a button, for example), thus making GUI unusable.

libX11's libxim module has a similar problem which has been fixed in libX11 trunk at least (I hope the patched version will be picked up by linux distribution soon.) During the debugging efforts that led to the discovery of the bug in libX11, someone noticed there is also a place in Xwnmo where timestamp is not properly set, and so I reported it in this bug report.

A few software packages other than Firefox, and Thunderbird are affected by such bogus timestamps.

GTK library seems to get stuck with a bogus timestamp well into the future, and once that happens, ff/tb and other programs may suffer.

Case in point 1:

A buggy version of unity window manager seems to have generated such events with bogus timestamps, and affected ff/tb.
https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/1016386

https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/1010466

Case in point 2:

Users of X11 XIM input mechanism including many Chinese and Japanese users. suffer from the symptoms mentioned here due to the bogus timestamps in X11 events passed around during XIM interaction: core libX11 has produced bogus timestamps(!)

https://bugzilla.mozilla.org/show_bug.cgi?id=787943

https://bugs.freedesktop.org/show_bug.cgi?id=39367

So I reported the bug.

TIA