bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[Kazuhiro Ito]

When I start Emacs with -Q option nd evaluate the below code, I get
unexpected result.

(let ((frame (selected-frame)))
  (lower-frame frame)
  ;; If we change the foreground window while sleeping, raise-frame
  ;; correctly works.
  (sleep-for 5)
  (raise-frame frame))

Result: raise-frame never raise the frame if the selected frame is the
foreground window.  If other frame or application is the foreground
window, raise-frame works as expected.

I guess SetForegroundWindow function does not modify Z-order when the
window is already foreground.  Below patch or similar workaround would
be needed.

=== modified file 'src/w32fns.c'
--- src/w32fns.c	2012-05-11 06:39:26 +0000
+++ src/w32fns.c	2012-05-18 11:24:26 +0000
@@ -3681,6 +3760,8 @@
 
         retval = SetForegroundWindow ((HWND) wParam);
 
+	BringWindowToTop ((HWND) wParam);
+
         /* Detach from the previous foreground thread.  */
         if (foreground_thread)
           AttachThreadInput (GetCurrentThreadId (),

-- 
Kazuhiro Ito

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[Eli Zaretskii]

> Date: Sat, 19 May 2012 06:06:09 +0900
> From: Kazuhiro Ito <kzhr@d1.dion.ne.jp>
> 
> When I start Emacs with -Q option nd evaluate the below code, I get
> unexpected result.
> 
> (let ((frame (selected-frame)))
>   (lower-frame frame)
>   ;; If we change the foreground window while sleeping, raise-frame
>   ;; correctly works.
>   (sleep-for 5)
>   (raise-frame frame))
> 
> Result: raise-frame never raise the frame if the selected frame is the
> foreground window.

I cannot reproduce this on my Windows XP system.  When I evaluate the
above, the Emacs frame is correctly lowered (i.e. goes behind the
other window(s)), and then is brought into the foreground several
seconds later.

> If other frame or application is the foreground window, raise-frame
> works as expected.

What exactly do you mean by "If other frame or application is the
foreground window"?  If the Emacs frame is the only foreground window
(i.e. all the others are iconified) when I evaluate the recipe, then
the Emacs frame is neither lowered nor raised, which I think is the
expected behavior.

So please specify more precisely the conditions for reproducing this
problem, in terms of what other windows should or should not be
present on the display before evaluating the recipe code.  Perhaps the
recipe lacks some specific mouse gestures to achieve the required
effect?

Also, please provide the details normally collected by
"M-x report-emacs-bug RET".  They are important.

Thanks.

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[Kazuhiro Ito]

> > When I start Emacs with -Q option nd evaluate the below code, I get
> > unexpected result.
> > 
> > (let ((frame (selected-frame)))
> >   (lower-frame frame)
> >   ;; If we change the foreground window while sleeping, raise-frame
> >   ;; correctly works.
> >   (sleep-for 5)
> >   (raise-frame frame))
> > 
> > Result: raise-frame never raise the frame if the selected frame is the
> > foreground window.
> 
> I cannot reproduce this on my Windows XP system.  When I evaluate the
> above, the Emacs frame is correctly lowered (i.e. goes behind the
> other window(s)), and then is brought into the foreground several
> seconds later.

The problem also occurs with pre-compiled pretest binary (*1) on
Windows XP and Windows 7 (Professional, x64) system.  In my
environment, when I evaluate the above code, Emacs frame is correctly
lowered too, but is not brought into the foreground.  Emacs frame
keeps behind the other application window(s).

(*1) http://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-24.0.97-bin-i386.zip

> > If other frame or application is the foreground window, raise-frame
> > works as expected.
>
> What exactly do you mean by "If other frame or application is the
> foreground window"?

If I change foreground application from Emacs to other application via
ALT + TAB or mouse click while Emacs runs sleep-for function in the
above code, Emacs frame is brought into the foreground several seconds
later.  that is the expected result.

> So please specify more precisely the conditions for reproducing this
> problem, in terms of what other windows should or should not be
> present on the display before evaluating the recipe code.  Perhaps the
> recipe lacks some specific mouse gestures to achieve the required
> effect?

1. Launch other Windows application (e.g. explorer, Command Prompt).
2. Start Emacs with -Q option.
3. Move Emacs frame to make it to overlap other application window(s)
 with mouse drag.
4. Yank the below code into *scratch* buffer.

(let ((frame (selected-frame)))
  (lower-frame frame)
  (sleep-for 5)
  (raise-frame frame))

5. Evaluate it with C-j.
6. Keep away from keyboard and mouse until Emacs finishes evaluation.

Result: Emacs frame is behind other application window(s).

Expected result: Emacs frame is in front of other application
window(s).

> Also, please provide the details normally collected by
> "M-x report-emacs-bug RET".

Here is the details with pretest binary.

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':



If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
f:/emacs-24.0.97/etc/DEBUG.


In GNU Emacs 24.0.97.1 (i386-mingw-nt6.1.7601)
 of 2012-05-17 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: JPN
  value of $XMODIFIERS: nil
  locale-coding-system: cp932
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<language-change> C-y C-j <escape> x r e p o r t <
return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date japan-util tooltip
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp
w32-win w32-vars tool-bar dnd fontset image fringe lisp-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)

-- 
Kazuhiro Ito

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[Eli Zaretskii]

> Date: Sat, 19 May 2012 21:02:21 +0900
> From: Kazuhiro Ito <kzhr@d1.dion.ne.jp>
> Cc: 11513@debbugs.gnu.org
> 
> 1. Launch other Windows application (e.g. explorer, Command Prompt).
> 2. Start Emacs with -Q option.
> 3. Move Emacs frame to make it to overlap other application window(s)
>  with mouse drag.
> 4. Yank the below code into *scratch* buffer.
> 
> (let ((frame (selected-frame)))
>   (lower-frame frame)
>   (sleep-for 5)
>   (raise-frame frame))
> 
> 5. Evaluate it with C-j.
> 6. Keep away from keyboard and mouse until Emacs finishes evaluation.
> 
> Result: Emacs frame is behind other application window(s).
> 
> Expected result: Emacs frame is in front of other application
> window(s).

Thanks.  I get the expected result on my system, with the latest
pretest binary.  The only differences I could think of that could
explain why we get different results are (1) I built the pretest
myself (will try the binary you used later); and (2) some Windows
configuration changes, either on your system or on mine, that make our
systems behave differently.

Would other Windows users please try reproducing this problem on their
machines?

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[martin rudalics]

> Would other Windows users please try reproducing this problem on their
> machines?

Not reproducible on Windows XP.  Tested with release and trunk, both
built by myself.

martin

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[Eli Zaretskii]

> Date: Sat, 19 May 2012 14:56:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Kazuhiro Ito <kzhr@d1.dion.ne.jp>, 11513@debbugs.gnu.org
> 
> > Would other Windows users please try reproducing this problem on their
> > machines?
> 
> Not reproducible on Windows XP.  Tested with release and trunk, both
> built by myself.

Thanks for testing.

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[Eli Zaretskii]

> Date: Sat, 19 May 2012 14:56:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Kazuhiro Ito <kzhr@d1.dion.ne.jp>, 11513@debbugs.gnu.org
> 
> > Would other Windows users please try reproducing this problem on their
> > machines?
> 
> Not reproducible on Windows XP.  Tested with release and trunk, both
> built by myself.

It's a very elusive problem.  I managed to reproduce it on 1 system
out of 3 to which I have constant access, and even that only for a few
minutes and under some conditions.  E.g., when lowering the frame left
only the left side of the Emacs frame visible, the bug would manifest
itself; whereas when its right side was visible, it won't.  And once I
reshuffled the other windows a bit, the bug disappeared and I couldn't
reproduce it anymore.

Do you get the faulty behavior consistently?  If so, what's your value
of this Registry key:

  HKEY_CURRENT_USER\Control Panel\Desktop\UserPreferencesMask

Anyway, back to the discussion, I notice that:

 . The documentation of SetForegroundWindow
   (http://msdn.microsoft.com/en-us/library/windows/desktop/ms633539%28v=vs.85%29.aspx)
   lists quite a few of conditions under which the function will
   succeed; are you sure at least one of them was true when you tried?
   can you look at the value of 'retval' after the function returns
   without bringing the frame to the foreground?

 . This page:

     http://stackoverflow.com/questions/1544179/what-are-the-differences-between-bringwindowtotop-setforegroundwindow-setwindo

   seems to tell that BringWindowToTop might fail as well, if it is
   applied to a child window.  What does this mean in terms of Emacs
   frames?

 . There are quite a few discussions about this that Google picks up,
   and most of them clearly say that using BringWindowToTop isn't
   sufficient, either.

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[Kazuhiro Ito]

At Mon, 21 May 2012 22:12:46 +0300,
Eli Zaretskii wrote:
> It's a very elusive problem.  I managed to reproduce it on 1 system
> out of 3 to which I have constant access, and even that only for a few
> minutes and under some conditions.  E.g., when lowering the frame left
> only the left side of the Emacs frame visible, the bug would manifest
> itself; whereas when its right side was visible, it won't.  And once I
> reshuffled the other windows a bit, the bug disappeared and I couldn't
> reproduce it anymore.
> 
> Do you get the faulty behavior consistently?

raise-frame always make the unexpected result when Emacs frame is
the foreground window (I mean Emacs frame is colored as active window)
and behind of other application window(s).  And, as I described
previously, If Emacs frame is not the foreground window raise-frame
correctly works.

> If so, what's your value of this Registry key:
>   HKEY_CURRENT_USER\Control Panel\Desktop\UserPreferencesMask

Key's value is '98 12 07 80 12 00 00 00'.

>  . The documentation of SetForegroundWindow
>    (http://msdn.microsoft.com/en-us/library/windows/desktop/ms633539%28v=vs.85%29.aspx)
>    lists quite a few of conditions under which the function will
>    succeed; are you sure at least one of them was true when you tried?
>    can you look at the value of 'retval' after the function returns
>    without bringing the frame to the foreground?

I believe that my test case qualifies some of conditions and I
confirmed SetForegroundWindow returns 1 even when the unexpected
result has been made.

>  . This page:
>      http://stackoverflow.com/questions/1544179/what-are-the-differences-between-bringwindowtotop-setforegroundwindow-setwindo
> 
>    seems to tell that BringWindowToTop might fail as well, if it is
>    applied to a child window.  What does this mean in terms of Emacs
>    frames?

I don't know exactly, but I think a child window is a windows created
with WS_CHILD style.  In Emacs, w32_createscrollbar would make scroll
bar as a child window.

-- 
Kazuhiro Ito

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[Eli Zaretskii]

> Date: Wed, 23 May 2012 19:48:59 +0900
> From: Kazuhiro Ito <kzhr@d1.dion.ne.jp>
> Cc: martin rudalics <rudalics@gmx.at>, 11513@debbugs.gnu.org
> 
> > Do you get the faulty behavior consistently?
> 
> raise-frame always make the unexpected result when Emacs frame is
> the foreground window (I mean Emacs frame is colored as active window)
> and behind of other application window(s).  And, as I described
> previously, If Emacs frame is not the foreground window raise-frame
> correctly works.

But the default behavior on Windows is that a window that is lowered
loses its focus.  You need to click into it to get focus there.  So
how come a lowered window still has focus for you?

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[Drew Adams]

> But the default behavior on Windows is that a window that is lowered
> loses its focus.  You need to click into it to get focus there.

Really?

Pick your favorite release, e.g. Emacs 23.3 or the latest Emacs 24 pretest, and
do this:

emacs -Q

C-x 5 2

Move a frame if necessary, so they overlap.

M-: (lower-frame)

The frame with the focus, where you typed `M-:', is lowered (moved to the back),
but it still has the input focus (is still selected).  `M-x' and other input
show up in its minibuffer, and its title bar is highlighted to indicate that it
is selected.

So I don't understand what you mean.  It sounds like what you are saying
contradicts what I see.

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[Kazuhiro Ito]

> > raise-frame always make the unexpected result when Emacs frame is
> > the foreground window (I mean Emacs frame is colored as active window)
> > and behind of other application window(s).  And, as I described
> > previously, If Emacs frame is not the foreground window raise-frame
> > correctly works.
> 
> But the default behavior on Windows is that a window that is lowered
> loses its focus.  You need to click into it to get focus there.  So
> how come a lowered window still has focus for you?

When I run lower-frame function in Emacs frame interactively, Emacs
frame is brought behind of other application window(s) but has focus.
Key inputs are passed to lowered frame.  I tested 4 Windows PC, and
all PCs show the same behavior.

-- 
Kazuhiro Ito

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[Lennart Borgman]

On Thu, May 24, 2012 at 8:04 AM, Kazuhiro Ito <kzhr@d1.dion.ne.jp> wrote:
>> > raise-frame always make the unexpected result when Emacs frame is
>> > the foreground window (I mean Emacs frame is colored as active window)
>> > and behind of other application window(s).  And, as I described
>> > previously, If Emacs frame is not the foreground window raise-frame
>> > correctly works.
>>
>> But the default behavior on Windows is that a window that is lowered
>> loses its focus.  You need to click into it to get focus there.  So
>> how come a lowered window still has focus for you?
>
> When I run lower-frame function in Emacs frame interactively, Emacs
> frame is brought behind of other application window(s) but has focus.
> Key inputs are passed to lowered frame.  I tested 4 Windows PC, and
> all PCs show the same behavior.

The same happens for me. On the other hand the doc string for
lower-frame does not say that the frame should loose focus.

bug#11513: 24.1.50; raise-frame never raise the foreground window on Windows

[Eli Zaretskii]

> Date: Thu, 24 May 2012 15:04:59 +0900
> From: Kazuhiro Ito <kzhr@d1.dion.ne.jp>
> Cc: rudalics@gmx.at, 11513@debbugs.gnu.org, drew.adams@oracle.com
> 
> > > raise-frame always make the unexpected result when Emacs frame is
> > > the foreground window (I mean Emacs frame is colored as active window)
> > > and behind of other application window(s).  And, as I described
> > > previously, If Emacs frame is not the foreground window raise-frame
> > > correctly works.
> > 
> > But the default behavior on Windows is that a window that is lowered
> > loses its focus.  You need to click into it to get focus there.  So
> > how come a lowered window still has focus for you?
> 
> When I run lower-frame function in Emacs frame interactively, Emacs
> frame is brought behind of other application window(s) but has focus.
> Key inputs are passed to lowered frame.  I tested 4 Windows PC, and
> all PCs show the same behavior.

Sorry, I was confused.  You are right, the focus isn't lost.

Anyway, I don't think it is a good idea to modify the reaction to the
WM_EMACS_SETFOREGROUND message, because it is also used by
x-focus-frame, which is not supposed to raise the frame to the top of
the Z-order, unless it is strictly necessary.  And if the frame is
already a foreground frame, raising it isn't necessary.

So instead I introduced a new message, WM_EMACS_BRINGTOTOP, and used
that in raise-frame.  The diffs are below (installed as revision
108409 on the trunk).

Thanks.  I'm closing this bug report.


=== modified file 'src/ChangeLog'
--- src/ChangeLog	2012-05-28 07:13:45 +0000
+++ src/ChangeLog	2012-05-28 17:22:40 +0000
@@ -1,3 +1,17 @@
+2012-05-28  Eli Zaretskii  <eliz@gnu.org>
+
+	* w32term.c (my_bring_window_to_top): New function.
+	(x_raise_frame): Use handle returned by DeferWindowPos, which
+	could be different from the original one.  Call
+	my_bring_window_to_top instead of my_set_foreground_window.
+	(Bug#11513)
+
+	* w32fns.c (w32_wnd_proc): Accept and process WM_EMACS_BRINGTOTOP
+	by calling BringWindowToTop.
+
+	* w32term.h (WM_EMACS_BRINGTOTOP): New message.
+	(WM_EMACS_END): Increase by one.
+
 2012-05-28  Paul Eggert  <eggert@cs.ucla.edu>
 
 	* bidi.c (bidi_mirror_char): Put eassert before conversion to int.

=== modified file 'src/w32fns.c'
--- src/w32fns.c	2012-05-25 18:19:24 +0000
+++ src/w32fns.c	2012-05-28 17:22:40 +0000
@@ -3663,6 +3663,7 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARA
     case WM_EMACS_SHOWWINDOW:
       return ShowWindow ((HWND) wParam, (WPARAM) lParam);
 
+    case WM_EMACS_BRINGTOTOP:
     case WM_EMACS_SETFOREGROUND:
       {
         HWND foreground_window;
@@ -3680,6 +3681,8 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARA
           foreground_thread = 0;
 
         retval = SetForegroundWindow ((HWND) wParam);
+        if (msg == WM_EMACS_BRINGTOTOP)
+          retval = BringWindowToTop ((HWND) wParam);
 
         /* Detach from the previous foreground thread.  */
         if (foreground_thread)

=== modified file 'src/w32term.c'
--- src/w32term.c	2012-05-18 08:36:50 +0000
+++ src/w32term.c	2012-05-28 17:22:40 +0000
@@ -3492,6 +3492,12 @@ my_destroy_window (struct frame * f, HWN
 	       (WPARAM) hwnd, 0);
 }
 
+static void
+my_bring_window_to_top (HWND hwnd)
+{
+  SendMessage (hwnd, WM_EMACS_BRINGTOTOP, (WPARAM) hwnd, 0);
+}
+
 /* Create a scroll bar and return the scroll bar vector for it.  W is
    the Emacs window on which to create the scroll bar. TOP, LEFT,
    WIDTH and HEIGHT are the pixel coordinates and dimensions of the
@@ -5600,24 +5606,27 @@ x_raise_frame (struct frame *f)
       HDWP handle = BeginDeferWindowPos (2);
       if (handle)
 	{
-	  DeferWindowPos (handle,
-			  FRAME_W32_WINDOW (f),
-  			  HWND_TOP,
-  			  0, 0, 0, 0,
-  			  SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE);
-
-	  DeferWindowPos (handle,
-			  GetForegroundWindow (),
-			  FRAME_W32_WINDOW (f),
-			  0, 0, 0, 0,
-			  SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE);
-
-	  EndDeferWindowPos (handle);
+	  handle = DeferWindowPos (handle,
+				   FRAME_W32_WINDOW (f),
+				   HWND_TOP,
+				   0, 0, 0, 0,
+				   SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE);
+	  if (handle)
+	    {
+	      handle = DeferWindowPos (handle,
+				       GetForegroundWindow (),
+				       FRAME_W32_WINDOW (f),
+				       0, 0, 0, 0,
+				       SWP_NOSIZE | SWP_NOMOVE |
+				       SWP_NOACTIVATE);
+	      if (handle)
+		EndDeferWindowPos (handle);
+	    }
 	}
     }
   else
     {
-      my_set_foreground_window (FRAME_W32_WINDOW (f));
+      my_bring_window_to_top (FRAME_W32_WINDOW (f));
     }
 
   UNBLOCK_INPUT;

=== modified file 'src/w32term.h'
--- src/w32term.h	2012-01-19 07:21:25 +0000
+++ src/w32term.h	2012-05-28 17:22:40 +0000
@@ -576,7 +576,8 @@ do { \
 #define WM_EMACS_HIDE_CARET            (WM_EMACS_START + 18)
 #define WM_EMACS_SETCURSOR             (WM_EMACS_START + 19)
 #define WM_EMACS_PAINT                 (WM_EMACS_START + 20)
-#define WM_EMACS_END                   (WM_EMACS_START + 21)
+#define WM_EMACS_BRINGTOTOP            (WM_EMACS_START + 21)
+#define WM_EMACS_END                   (WM_EMACS_START + 22)
 
 #define WND_FONTWIDTH_INDEX    (0)
 #define WND_LINEHEIGHT_INDEX   (4)