GNU bug report logs - #65116
29.1; query-replace-read-args fails reading second arg in detached minibuf

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Rees <jim <at> rees.org>
Cc: luangruo <at> yahoo.com, acm <at> muc.de, 65116 <at> debbugs.gnu.org
Subject: Re: bug#65116: 29.1; query-replace-read-args fails reading second
 arg in detached minibuf
Date: Sun, 14 Jan 2024 08:21:13 +0200

> Date: Sat, 13 Jan 2024 17:53:17 -0600
> From: Jim Rees <jim <at> rees.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>,
> 	65116 <at> debbugs.gnu.org
> 
> Yes that fixed it. Thanks.

Can you please revert that change, and instead test the patch below?
It was recently installed on the master branch of Emacs.

diff --git a/src/xterm.c b/src/xterm.c
index 77d6550..fe39817 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -13370,13 +13370,12 @@ xi_focus_handle_for_device (struct x_display_info *dpyinfo,
 	 frame's user time.  */
       x_display_set_last_user_time (dpyinfo, event->time,
 				    event->send_event, false);
-
       device->focus_frame = NULL;
 
       /* So, unfortunately, the X Input Extension is implemented such
-	 that means XI_Leave events will not have their focus field
-	 set if the core focus is transferred to another window after
-	 an entry event that pretends to (or really does) set the
+	 that XI_Leave events will not have their focus field set if
+	 the core focus is transferred to another window after an
+	 entry event that pretends to (or really does) set the
 	 implicit focus.  In addition, if the core focus is set, but
 	 the extension focus on the client pointer is not, all
 	 XI_Enter events will have their focus fields set, despite not
@@ -28805,6 +28804,33 @@ x_focus_frame (struct frame *f, bool noactivate)
      friends being set.  */
   block_input ();
 
+#ifdef HAVE_GTK3
+  /* read_minibuf assumes that calling Fx_focus_frame on a frame that
+     is already selected won't move the focus elsewhere, and thereby
+     disrupt any focus redirection to e.g. a minibuffer frame that
+     might be activated between that call being made and the
+     consequent XI_FocusIn/Out events arriving.  This is true whether
+     the focus is ultimately transferred back to the frame it was
+     initially on or not.
+
+     GTK 3 moves the keyboard focus to the edit widget's window
+     whenever it receives a FocusIn event targeting the outer window.
+     This operation gives rise to a FocusOut event that clears
+     device->focus_frame, which in turn prompts xi_handle_focus_change
+     to clear the display's focus frame.  The next FocusIn event
+     destined for the same frame registers as a new focus, which
+     cancels any focus redirection from that frame.
+
+     To prevent this chain of events from disrupting focus redirection
+     when the minibuffer is activated twice in rapid succession while
+     configured to redirect focus to a minibuffer frame, ignore frames
+     which hold the input focus and are connected to a minibuffer
+     window.  (bug#65116)*/
+
+  if (f == dpyinfo->x_focus_frame && !FRAME_HAS_MINIBUF_P (f))
+    return;
+#endif /* HAVE_GTK3 */
+
   if (FRAME_X_EMBEDDED_P (f))
     /* For Xembedded frames, normally the embedder forwards key
        events.  See XEmbed Protocol Specification at

Previous Next

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