GNU bug report logs - #11732
26.1; Japanese IME input problem on Windows

Previous Next

Full log

Message #130 received at 11732 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11732 <at> debbugs.gnu.org, mhatta <at> gmail.com
Subject: Re: bug#11732: Follow-up to bug#11732
Date: Tue, 03 Jul 2018 10:29:59 +0200

> The dialog appears on top of the frame from which it was invoked as
> usual, and as expected (since Windows raises the frame when you click
> on its menu, the frame is indeed usually on top of the other apps,
> modulo apps like Task Manager that force themselves on top of
> everything).  Then any click _anywhere_ inside the dialog causes the
> dialog to disappear, because the owning frame is raised to cover it.
> A second click at the same coordinates causes the dialog to be shown
> blinking, as when you click on some part outside the dialog.

Confirmed (finally, it took me some time to get my Windows 7 version
up and running again) with the autoraising option set.  The blinking
might be caused by some z-order fight maybe stopped by some timeout.

> My
> workaround for that is to drag the dialog outside of its owning frame,
> and then use it as usual.

That's no workaround on my Thinkpad.  The two windows will always
overlap each other and I cannot shrink any of them because Windows
does not allow it.

> Did I explain the situation clearly?

You did.

> Btw, I have now established that focus follows mouse causes this: if I
> disable it, the problem disappears.  And autoraise doesn't affect the
> issue in any way.  I tried both X-Mouse Controls and Winaero Tweaker,
> on 2 different Windows 7 systems, with the same result: enabling
> focus-follows-mouse causes the issue, disabling it makes the issue go
> away.  (Of course, both Windows 7 systems were configured by yours
> truly, so maybe there's some other factor acting as a catalyst.  But
> all else being equal, just turning on and off focus-follows-mouse
> causes the problem to appear or disappear on those 2 systems.)

No further explanations needed, the problem is clearly visible here
now.  Do you have any explanation why calling DefWindowProc when
handling WM_IME_STARTCOMPOSITION causes this aberrant behavior and not
any of the other cases where we call DefWindowProc?

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.