master c566ee9d06c: Fix bug#65116

[Po Lu]

branch: master
commit c566ee9d06caa80c120dd8631eb3dee17e152fc9
Author: Po Lu <luangruo@yahoo.com>
Commit: Po Lu <luangruo@yahoo.com>

    Fix bug#65116
    
    * src/xterm.c (xi_focus_handle_for_device): Correct typo.
    (x_focus_frame): Don't focus frames Emacs believes to be
    focused if they are frames with independent minibuffer
    frames.  (bug#65116)
---
 src/xterm.c | 34 ++++++++++++++++++++++++++++++----
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/src/xterm.c b/src/xterm.c
index 77d6550c8b9..fe398171754 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