Subject: bug#11732: Follow-up to bug#11732

From: martin rudalics <[email-masked]>
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