GNU bug report logs - #60356
30.0.50; individual frame loses keyboard focus, focus cannot be restored

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Linus Heckemann <git <at> sphalerite.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 60356 <at> debbugs.gnu.org
Subject: bug#60356: 30.0.50; individual frame loses keyboard focus, focus cannot be restored
Date: Wed, 04 Jan 2023 09:08:57 +0800

Would you please do what I asked earlier, namely:

git <at> sphalerite.org writes:

> The exact action leading to this bug is not clear to me. It seems to be
> related to lsp-mode though -- I've not observed it happening without
> lsp-mode.
>
> The symptom is that a single frame will no longer accept keyboard input,
> and will visually indicate that it is not focused (outline rectangular
> cursor where I'd usually expect a solid rectangular cursor). Mouse input
> still works, and other frames still accept keyboard input as normal.
>
> I'd be glad if anyone could point out ways to further debug this issue.
> I'm also in #emacs:matrix.org (@linus:schreibt.jetzt) in case
> fast-turnaround communication would be helpful :)

Can you reliably reproduce this issue?

If you can, please add some instrumentation to x_new_focus_frame, like
this:

diff --git a/src/xterm.c b/src/xterm.c
index 1eef8e7a724..cda2897e013 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -11695,6 +11695,9 @@ x_new_focus_frame (struct x_display_info *dpyinfo, struct frame *frame)
     }
 #endif
 
+  fprintf (stderr, "x_new_focus_frame: switching focus to"
+	   " %s\n", SSDATA (frame->name));
+
   if (frame != dpyinfo->x_focus_frame)
     {
       /* Set this before calling other routines, so that they see

and see what is printed out when you try to focus the frame that does
not accept input.  Thanks.

Previous Next

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