It has been almost full week.

I have NOT had a single occurrence of the problem of pull-down menu
not showing correctly for the full week after I applied the patch(es).
So as far as my user experience is concerned, the patch(es) have
improved it very much!  I have less frustration on my linux desktop
now.

I am attaching a slightly renewed patch here.

I added another initialization for buf32 in imDefLkup.c: access to
uninitialized buf32 DID HAPPEN during my testing and random value may
lead to the crash. (Of course, why this happened is anybody's guess.)

Anyway, all those incorrect timestamp issues are gone!
Well almost. (See the warnings below.)

I wonder this also applies to people who use Chinese input engine.

[WARNINGS]

During the whole time (one full week now), the ill-effect of timestamp
being 0 may not be that obvious, if any.

Only THREE (3) warnings I got during the last week's operation from
the window manager after my fix in ~/.xsession-errors:

As usual "ウィンドウ・マネージャーの警告" means "Warning from the Window Manager"
in Japanese.

(1) I got the following sequence of messages TWICE:

ウィンドウ・マネージャーの警告: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x460008e (Iceweasel)
ウィンドウ・マネージャーの警告: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.

metacity is fuzzy about this issue, and states that this problem can
be ignored for now (in the source file, that is).  And its definition
of "pager" is very fuzzy, too.

(2) Not sure if the following message is related to my fix. Already
GTK library had an issue with the menu system : (see the thread which
includes this post: Re: X11 timestamp problems? ( "Re: Minutes of the
GNOME Board meeting 19 March 2001" ) from Jim Gettys
https://mail.gnome.org/archives/gtk-devel-list/2001-March/msg00563.html

ウィンドウ・マネージャーの警告: GtkMenu failed to grab the pointer

(3) ??? transient problem caused by the replacement of libX11 ???

The following is a series of messges I got once: this could be a real
problem. Or these are transient errors caused because I was replacing
the libx11 library with different dump message:

(gnome-settings-daemon:18356): color-plugin-WARNING **: not found device (null): Failed to FindDeviceByProperty: GDBus.Error:org.freedesktop.ColorManager.Failed: property match 'XRANDR_name'='default' does not exist
gnome-session[18281]: WARNING: Client '/org/gnome/SessionManager/Client31' failed to reply before timeout
gnome-session[18281]: WARNING: Unable to find desktop file 'thunderbird.desktop': 検索ディレクトリには妥当なキー・ファイルがありませんでした
gnome-session[18281]: WARNING: Unable to find desktop file 'gnome-thunderbird.desktop': 検索ディレクトリには妥当なキー・ファイルがありませんでした
ウィンドウ・マネージャーの警告: CurrentTime used to choose focus window; focus window may not be correct.
ウィンドウ・マネージャーの警告: Got a request to focus the no_focus_window with a timestamp of 0.  This shouldn't happen!
(gnome-settings-daemon:18356): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
** Message: applet now removed from the notification area
(gnome-sound-applet:18403): Gdk-WARNING **: gnome-sound-applet: Fatal IO error 11 (リソースが一時的に利用できません) on X server :0.


[Renewed Patch]

I can only say that the following patch(es) have resolved my issues for now.
I think trying to fill in the time-field with Xserver time is an overkill
and may be a real overhead for XIM routine.
(In Japanese, I found that the fixed portion is invoked only when
the input is confirmed and passed to the application, but
I don't know how it is used by Chinese and Korean input applicastions.
If these parts are executed often (every keystroke or so), then
the added overhead to obtain the timestamp would cause a 
very negative user experience. Imagine that you are running an application
on remote machine and that you are typing into to it and each keystroke
causes extra context switch and network round trip due to such fectching of
xserver time.

Here is the renwed patch (the lines may be a little off to your source
due to the removed lines for additional dumps).


diff --git a/modules/im/ximcp/imTrans.c b/modules/im/ximcp/imTrans.c
index 0ac08aa..aefee2a 100644
--- a/modules/im/ximcp/imTrans.c
+++ b/modules/im/ximcp/imTrans.c
@@ -222,12 +222,20 @@ _XimTransInternalConnection(
 
     if (spec->is_putback)
 	return;
+
+    bzero(&ev, sizeof(ev));	/* FIXME: other fields may be accessed, too. */
     kev = (XKeyEvent *)&ev;
     kev->type = KeyPress;
     kev->send_event = False;
     kev->display = im->core.display;
     kev->window = spec->window;
     kev->keycode = 0;
+    /* FIXME */
+    kev->time = 0L;
+    kev->serial = LastKnownRequestProcessed(im->core.display);
+    fprintf(stderr,"%s,%d: putback FIXED kev->time=0 kev->serial=%lu\n", __FILE__, __LINE__, kev->serial);
+
+
     XPutBackEvent(im->core.display, &ev);
     XFlush(im->core.display);
     spec->is_putback = True;


diff --git a/modules/im/ximcp/imDefLkup.c b/modules/im/ximcp/imDefLkup.c
index cf75919..fb8c07d 100644
--- a/modules/im/ximcp/imDefLkup.c
+++ b/modules/im/ximcp/imDefLkup.c
@@ -269,6 +269,8 @@ _XimForwardEventCore(
     int		 ret_code;
     INT16	 len;
 
+    bzero(buf32, sizeof(buf32)); /* valgrind noticed uninitialized memory use! */
+
     if (!(len = _XimSetEventToWire(ev, (xEvent *)&buf_s[4])))
 	return False;				/* X event */
 
@@ -706,6 +723,8 @@ _XimCommitRecv(
 
     MARK_FABRICATED(im);
 
+    bzero(&ev, sizeof(ev));	/* running kterm under valgrind */
+
     ev.type = KeyPress;
     ev.send_event = False;
     ev.display = im->core.display;
@@ -713,6 +732,14 @@ _XimCommitRecv(
     ev.keycode = 0;
     ev.state = 0;
 
+    ev.time = 0L;
+    ev.serial = LastKnownRequestProcessed(im->core.display);
+    /* FIXME : 
+       I wish there were COMMENTs (!) about the data passed around.
+    */
+    fprintf(stderr,"%s,%d: putback k press   FIXED ev.time=0 ev.serial=%lu\n", __FILE__, __LINE__, ev.serial);
+
+
     XPutBackEvent(im->core.display, (XEvent *)&ev);
 
     return True;