bug#23174: Windows : Emacs frame stays on top after Alt-Tab

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: devi8@null.net
>> Date: Thu, 31 Mar 2016 11:17:26 +0200
>>
>> GNU Emacs 24.5.1 (i686-pc-mingw32) of 2015-04-11 on LEG570
>>
>> On Windows (7 Professional), after (?) switching from a Aero Desktop Theme 
>> back to a non-Aero Desktop Theme,
>> pressing Alt-Tab will switch application windows, but the Emacs Window 
>> ("Frame"?) will stay on the foreground, which is wrong behaviour.
>> Only after exiting and restarting Emacs is the correct behaviour restored 
>> again, and Alt-Tab works as expected.
>>
>> I saw some discussions on the use of SetForegroundWindow and some bug 
>> reports that might relate to this.
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=6468
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11513
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13954
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11513
>>
>> In general I despise applications that use SetForegroundWindow, because 
>> almost all of them fail to do what the user wants, because of lack of 
>> knowledge of other active applications and the user's intentions.
>> This bug report is also an example of such behaviour.
>>
>> Why not totally remove the use of SetForegroundWindow (except maybe for 
>> sys_kill and some places that try to fix "bugs"), or at least make it 
>> customizable so that I can disable it?
>
> You may be right, but please explain how are the calls to
> SetForegroundWindow related to the problem you describe.  IOW, please
> tell the details of how Alt-TAB winds up calling that API, or how the
> call to that API interferes with Alt-TAB.
>
> Emacs calls SetForegroundWindow in only 2 specific situations: when it
> was requested to direct a focus to a frame, and when it was requested
> to raise a frame.  I don't necessarily see how is that related to the
> issue at hand.
>
> I also couldn't reproduce the problem, on Windows 8.1 and Emacs 24.5.
> Maybe I don't quite understand what you did, so please describe the
> recipe for reproducing the problem step by step, preferably starting
> with "emacs -Q".

More information was requested, but was not given within three years.
I'm therefore closing this bug report.  If anyone can reproduce this
issue, please reopen.

Best regards,
Stefan Kangas