bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame

[martin rudalics <rudalics@gmx.at>]

 >> It should not deliberately raise a frame that already has focus.
 >
 > OK.  We could add an extra check for the frame already having the focus.
 > Is there anything else suboptimal about that proposed fix to emacs-28?

If by "extra check" you mean

diff --git a/src/minibuf.c b/src/minibuf.c
index 0fc7f2caa1..71fd62cede 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -896,6 +896,12 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
    /* Don't allow the user to undo past this point.  */
    bset_undo_list (current_buffer, Qnil);

+  /* If some Emacs frame currently has the window-system focus, give
+     it to the minibuffer frame.  This is sometimes needed for
+     minibuffer-only frames.  */
+  if (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame)
+    Fx_focus_frame (mini_frame, Qt);
+
    recursive_edit_1 ();

    /* If cursor is on the minibuffer line,

then it does not improve anything here - the minibuffer frame is first
lowered and then raised above the normal frame.  I do not understand the
idea here anyway.  Why give focus to a frame that already has focus?
Why does the comment say "some Emacs frame" while the code checks only
the minibuffer frame?

Recalling my personal experience: I used 'x-focus-frame' in one special
case only - in 'handle-select-window' when 'focus-follows-mouse' is
non-nil.  All other calls are via 'select-frame-set-input-focus' where
the intention to _also_ raise the frame is obvious.  I would never have
called 'x-focus-frame' from C with the default settings - every second
window manager out there will handle it differently.

 > In the mean time, how well does the change to master work?  It attempts
 > to fix the cause of (rather than just working around) bug #56305.

The change to master fixes the bug here.

martin