GNU bug report logs - #79098
31.0.50; quit-window raises frame, steals focus

Previous Next

To reply to this bug, email your comments to 79098 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

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

From: Óscar Fuentes <oscarfv <at> eclipso.eu>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; quit-window raises frame, steals focus
Date: Fri, 25 Jul 2025 23:18:46 +0200

emacs -Q

Split window so window 1 shows *scratch* and window 2 shows *Messages*

Eval this in *scratch* and, before 5 seconds, switch the focus to some
other application's frame that obscures Emacs' frame:

(run-with-timer
 5 nil
 (lambda ()
   (quit-window nil (other-window-for-scrolling))))

When the timer executes, Emacs' frame will be raised and given focus.

Something similar happens in MSWindows, so this is not an artifact
specific to my desktop manager (KDE 6.3 on my case.)


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.18.4) of 2025-07-25 built on sky
Repository revision: 33161e51e539eadeb11282c06df73a5d76afdff2
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Debian GNU/Linux 13 (trixie)

Configured using:
 'configure --with-native-compilation --with-tree-sitter
 --without-toolkit-scroll-bars --with-x-toolkit=lucid --with-modules
 --without-imagemagick'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBOTF
LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PNG SECCOMP SOUND SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XAW3D XDBE
XIM XINERAMA XINPUT2 XPM XRANDR LUCID ZLIB

Important settings:
  value of $LANG: es_ES.UTF-8
  locale-coding-system: utf-8-unix

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

From: Óscar Fuentes <oscarfv <at> eclipso.eu>
To: 79098 <at> debbugs.gnu.org
Cc: Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#79098: 31.0.50; quit-window raises frame, steals focus
Date: Sun, 27 Jul 2025 02:22:44 +0200

> emacs -Q
>
> Split window so window 1 shows *scratch* and window 2 shows *Messages*
>
> Eval this in *scratch* and, before 5 seconds, switch the focus to some
> other application's frame that obscures Emacs' frame:
>
> (run-with-timer
>  5 nil
>  (lambda ()
>    (quit-window nil (other-window-for-scrolling))))
>
> When the timer executes, Emacs' frame will be raised and given focus.
>
> Something similar happens in MSWindows, so this is not an artifact
> specific to my desktop manager (KDE 6.3 on my case.)


quit-window calls quit-restore-window, which calls
window--quit-restore-select-window, and this function introduced the
problem:

commit 9f4347e00c02c3aa436118425a0cda2bc7f69d51
Author: Juri Linkov <juri <at> linkov.net>
Date:   Thu Apr 17 21:21:29 2025 +0300

    Don't switch to another frame if window is not on the selected frame.
    
    * lisp/window.el (window--quit-restore-select-window):
    Add optional arg 'frame'.  Don't switch to another frame
    if window is not on the selected frame (bug#71386).
    (quit-restore-window): Provide the 'frame' arg
    to 'window--quit-restore-select-window' calls.
    Patch by martin rudalics <rudalics <at> gmx.at>.
    
    * test/lisp/tab-bar-tests.el (tab-bar-tests-quit-restore-window):
    No need to reselect the frame after 'quit-window'.

diff --git a/lisp/window.el b/lisp/window.el
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -5338,166 +5338,173 @@
-(defun window--quit-restore-select-window (window)
+(defun window--quit-restore-select-window (window &optional frame)
   "Select WINDOW after having quit another one.
 Do not select an inactive minibuffer window."
   (when (and (window-live-p window)
              (or (not (window-minibuffer-p window))
                  (minibuffer-window-active-p window)))
-    (select-window window)))
+    ;; If WINDOW is not on the selected frame, don't switch to
+    ;; another frame.
+    (unless (and (eq frame (selected-frame))
+		 (not (eq frame (window-frame window))))
+      (setq frame (window-frame window))
+      (set-frame-selected-window frame window)
+      (select-frame-set-input-focus frame))))

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79098 <at> debbugs.gnu.org,
 Óscar Fuentes <oscarfv <at> eclipso.eu>
Subject: Re: bug#79098: 31.0.50; quit-window raises frame, steals focus
Date: Sun, 27 Jul 2025 09:41:42 +0300

>> emacs -Q
>>
>> Split window so window 1 shows *scratch* and window 2 shows *Messages*
>>
>> Eval this in *scratch* and, before 5 seconds, switch the focus to some
>> other application's frame that obscures Emacs' frame:
>>
>> (run-with-timer
>>  5 nil
>>  (lambda ()
>>    (quit-window nil (other-window-for-scrolling))))
>>
>> When the timer executes, Emacs' frame will be raised and given focus.
>>
>> Something similar happens in MSWindows, so this is not an artifact
>> specific to my desktop manager (KDE 6.3 on my case.)

I confirm the problem on the Mint MATE desktop.

> quit-window calls quit-restore-window, which calls
> window--quit-restore-select-window, and this function introduced the
> problem:

Martin, should we revert this patch?

> commit 9f4347e00c02c3aa436118425a0cda2bc7f69d51
> Author: Juri Linkov <juri <at> linkov.net>
> Date:   Thu Apr 17 21:21:29 2025 +0300
>
>     Don't switch to another frame if window is not on the selected frame.
>     
>     * lisp/window.el (window--quit-restore-select-window):
>     Add optional arg 'frame'.  Don't switch to another frame
>     if window is not on the selected frame (bug#71386).
>     (quit-restore-window): Provide the 'frame' arg
>     to 'window--quit-restore-select-window' calls.
>     Patch by martin rudalics <rudalics <at> gmx.at>.
>     
>     * test/lisp/tab-bar-tests.el (tab-bar-tests-quit-restore-window):
>     No need to reselect the frame after 'quit-window'.
>
> diff --git a/lisp/window.el b/lisp/window.el
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -5338,166 +5338,173 @@
> -(defun window--quit-restore-select-window (window)
> +(defun window--quit-restore-select-window (window &optional frame)
>    "Select WINDOW after having quit another one.
>  Do not select an inactive minibuffer window."
>    (when (and (window-live-p window)
>               (or (not (window-minibuffer-p window))
>                   (minibuffer-window-active-p window)))
> -    (select-window window)))
> +    ;; If WINDOW is not on the selected frame, don't switch to
> +    ;; another frame.
> +    (unless (and (eq frame (selected-frame))
> +		 (not (eq frame (window-frame window))))
> +      (setq frame (window-frame window))
> +      (set-frame-selected-window frame window)
> +      (select-frame-set-input-focus frame))))

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 79098 <at> debbugs.gnu.org, Óscar Fuentes <oscarfv <at> eclipso.eu>
Subject: Re: bug#79098: 31.0.50; quit-window raises frame, steals focus
Date: Sun, 27 Jul 2025 10:07:21 +0200

> Martin, should we revert this patch?

Let's just use 'select-frame' here

>> +      (select-frame-set-input-focus frame))))

and see whether it causes problems elsewhere (I was probably concerned
about focus for the rare case that a user wants to quit a window during
a minibuffer interaction).  BTW I have forbidden focus stealing here, so
I wouldn't observe behaviors like in Óscar's scenario.

martin

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79098 <at> debbugs.gnu.org,
 Óscar Fuentes <oscarfv <at> eclipso.eu>
Subject: Re: bug#79098: 31.0.50; quit-window raises frame, steals focus
Date: Sun, 27 Jul 2025 19:30:50 +0300

close 79098 31.0.50
thanks

> Let's just use 'select-frame' here
>
>>> +      (select-frame-set-input-focus frame))))
>
> and see whether it causes problems elsewhere (I was probably concerned
> about focus for the rare case that a user wants to quit a window during
> a minibuffer interaction).  BTW I have forbidden focus stealing here, so
> I wouldn't observe behaviors like in Óscar's scenario.

Thanks for the suggestion, now fixed.

Previous Next

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