bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Bob Rogers]

   I have a number of independent emacs sessions, each with a single GUI
frame, some remote via SSH and some as root.  In the sessions using
emacs built recently from master with blink-cursor-mode enabled, the
cursor continues to blink even when the (single) frame loses focus, when
it should become a steady hollow box.  This also happens in "emacs -Q"
(somewhat intermittently, along with failure to start blinking, and some
stranger things).  The following test code:

	(let ((count 0))
	  (while t
	    (message "focus state at %d:  %S"
		     (cl-incf count) (frame-focus-state))
	    (sit-for 2)))

shows that the focus state never changes from `t'.  The problem appears
to be that handle-focus-out is never called, but I don't know the emacs
window system interface well enough to follow it any farther.

   FWIW, the problem doesn't happen in 28.1, or in an emacs built from
the master branch on 24-May.  I should also mention that one of my
sessions started behaving properly again while I was trying to debug
this, but I have no idea what, if anything, I did.  Also, this is under
KDE/Plasma on X11 in a recent openSUSE Leap 15.4 upgrade, so there may
be an underlying window system issue.

   TIA,

					-- Bob Rogers
					   http://www.rgrjr.com/

------------------------------------------------------------------------
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.16.0)
 of 2022-08-20 built on orion
Repository revision: 7e9d744033f07286c21f092f8ea3646a51e37a19
Repository branch: rgr-smtpmail-env-from
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: openSUSE Leap 15.4

Configured using:
 'configure --with-dbus=no --with-gsettings=no --with-gif=ifavailable
 --with-tiff=no --with-gnutls=yes --with-gconf=no'

Configured features:
ACL CAIRO FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBSELINUX LIBXML2
MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS
TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

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

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Lars Ingebrigtsen]

Bob Rogers <rogers@rgrjr.com> writes:

>    I have a number of independent emacs sessions, each with a single GUI
> frame, some remote via SSH and some as root.  In the sessions using
> emacs built recently from master with blink-cursor-mode enabled, the
> cursor continues to blink even when the (single) frame loses focus, when
> it should become a steady hollow box.  This also happens in "emacs -Q"
> (somewhat intermittently, along with failure to start blinking, and some
> stranger things).

I'm unable to reproduce this, and it doesn't fail to start blinking,
either.

> In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.16.0)
>  of 2022-08-20 built on orion
> Repository revision: 7e9d744033f07286c21f092f8ea3646a51e37a19
> Repository branch: rgr-smtpmail-env-from
> Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
> System Description: openSUSE Leap 15.4

This doesn't really say which Emacs repo version you're using --
7e9d744033f07286c21f092f8ea3646a51e37a19 isn't an Emacs git hash.

Could you try using the current version from the Emacs repo to see if
you see the problem there?

For reference, here's my build data:

In GNU Emacs 29.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
 3.24.33, cairo version 1.16.0) of 2022-08-29 built on joga
Repository revision: 6f57cb6d8141e35fee39ea31f08d4ce5cf6c51e5
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Ubuntu 22.04.1 LTS

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Bob Rogers]

   From: Lars Ingebrigtsen <larsi@gnus.org>
   Date: Mon, 29 Aug 2022 17:21:15 +0200

   Bob Rogers <rogers@rgrjr.com> writes:

   >    I have a number of independent emacs sessions, each with a single GUI
   > frame, some remote via SSH and some as root.  In the sessions using
   > emacs built recently from master with blink-cursor-mode enabled, the
   > cursor continues to blink even when the (single) frame loses focus, when
   > it should become a steady hollow box.  This also happens in "emacs -Q"
   > (somewhat intermittently, along with failure to start blinking, and some
   > stranger things).

   I'm unable to reproduce this, and it doesn't fail to start blinking,
   either.

I was afraid of that.

   > In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.16.0)
   >  of 2022-08-20 built on orion
   > Repository revision: 7e9d744033f07286c21f092f8ea3646a51e37a19
   > Repository branch: rgr-smtpmail-env-from
   > Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
   > System Description: openSUSE Leap 15.4

   This doesn't really say which Emacs repo version you're using --
   7e9d744033f07286c21f092f8ea3646a51e37a19 isn't an Emacs git hash.

Oops; that's for a local branch that just hacks lisp/mail/smtpmail.el.
It's based on 07c04da01016cd81e064a06b2449892eff7c8da0 on master.

   Could you try using the current version from the Emacs repo to see if
   you see the problem there?

Still happens, commit 9f692bcd84e2b6e450e154361e1058186e6481a8.

   FWIW, chromium also has a cursor that blinks if you click on page
elements, but stops when chromium loses focus.

					-- Bob

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Lars Ingebrigtsen]

Bob Rogers <rogers@rgrjr.com> writes:

>    I'm unable to reproduce this, and it doesn't fail to start blinking,
>    either.
>
> I was afraid of that.

I tried on a couple machines, and the blinking stops reliably for me.

Anybody have any ideas how to debug this?  Could it be the window
manager that's not sending Emacs the de-focus event (or whatever it's
called)?

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Eli Zaretskii]

> Cc: 57468@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 30 Aug 2022 12:27:00 +0200
> 
> Could it be the window manager that's not sending Emacs the de-focus
> event (or whatever it's called)?

That should be easy to verify by binding a command to the event that
will display the event.  The focus-in "pseudo-key" is defined in the
special-event-map.

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Bob Rogers]

   From: Eli Zaretskii <eliz@gnu.org>
   Date: Tue, 30 Aug 2022 15:02:17 +0300

   > Cc: 57468@debbugs.gnu.org
   > From: Lars Ingebrigtsen <larsi@gnus.org>
   > Date: Tue, 30 Aug 2022 12:27:00 +0200
   > 
   > Could it be the window manager that's not sending Emacs the de-focus
   > event (or whatever it's called)?

   That should be easy to verify by binding a command to the event that
   will display the event.  The focus-in "pseudo-key" is defined in the
   special-event-map.

When I went back to my console, I found to my consternation that two
local emacs instances plus a new "src/emacs -Q" all behaved correctly,
despite not having touched anything since my last email that might
conceivably have an effect.  Persevering, I used the following code to
track events:

	(defun rgr-focus-in () (interactive) (message "focus in"))
	(define-key special-event-map [ focus-in ] 'rgr-focus-in)
	(defun rgr-focus-out () (interactive) (message "focus out"))
	(define-key special-event-map [ focus-out ] 'rgr-focus-out)

And got the expected correct behavior.

   Then I brought up a pre-existing emacs instance running as root
(which I had forgotten about) and found that its blinking cursor stays
on persistently, and the focus in/out code above shows that it's getting
neither event.  (I don't remember if I tested this instance when
reporting the bug two days ago, but I suspect I did and that it was
normal.)

					-- Bob

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Lars Ingebrigtsen]

Bob Rogers <rogers@rgrjr.com> writes:

>    Then I brought up a pre-existing emacs instance running as root
> (which I had forgotten about) and found that its blinking cursor stays
> on persistently, and the focus in/out code above shows that it's getting
> neither event.

How was the root Emacs started?  Could it be in a way that stops the
window manager from delivering events to it?

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Bob Rogers]

   From: Lars Ingebrigtsen <larsi@gnus.org>
   Date: Wed, 31 Aug 2022 12:03:38 +0200

   Bob Rogers <rogers@rgrjr.com> writes:

   >    Then I brought up a pre-existing emacs instance running as root
   > (which I had forgotten about) and found that its blinking cursor stays
   > on persistently, and the focus in/out code above shows that it's getting
   > neither event.

   How was the root Emacs started?  Could it be in a way that stops the
   window manager from delivering events to it?

Just "emacs &" after "su" in a shell.  I should emphasize that I've seen
nothing special about the root emacs; all instances save one switched
between working and nonworking at long but unpredictable intervals.  And
the other problematic instances were also spawned from shells, though
some were from a Konsole shell, some were via ssh with tunneled X11, and
some from an emacs shell window.

   I've also tried a slightly newer version of master (commit
136495f178ccd36b23ffc347fe2b6680fd689e34) on the previous openSUSE
release, and the cursor behaves normally WRT focus-in/out.  Here's what
report-emacs-bug says about the installation:

	Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
	System Description: openSUSE Leap 15.3

This is under KDE/Plasma, apparently version 5.18.5.

					-- Bob

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Eli Zaretskii]

> From: Bob Rogers <rogers@rgrjr.com>
> Date: Wed, 31 Aug 2022 12:02:04 -0700
> CC: Eli Zaretskii <eliz@gnu.org>, 57468@debbugs.gnu.org
> 
>    From: Lars Ingebrigtsen <larsi@gnus.org>
>    Date: Wed, 31 Aug 2022 12:03:38 +0200
> 
>    Bob Rogers <rogers@rgrjr.com> writes:
> 
>    >    Then I brought up a pre-existing emacs instance running as root
>    > (which I had forgotten about) and found that its blinking cursor stays
>    > on persistently, and the focus in/out code above shows that it's getting
>    > neither event.
> 
>    How was the root Emacs started?  Could it be in a way that stops the
>    window manager from delivering events to it?
> 
> Just "emacs &" after "su" in a shell.  I should emphasize that I've seen
> nothing special about the root emacs; all instances save one switched
> between working and nonworking at long but unpredictable intervals.  And
> the other problematic instances were also spawned from shells, though
> some were from a Konsole shell, some were via ssh with tunneled X11, and
> some from an emacs shell window.

I guess the next step is to set a breakpoint in every place where we
call x_focus_changed, and see whether the X events are delivered to
Emacs in the "su" Emacs.  If the events aren't delivered, this is not
an Emacs problem.

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Bob Rogers]

   From: Bob Rogers <rogers@rgrjr.com>
   Date: Wed, 31 Aug 2022 12:02:04 -0700

   . . .

   I've also tried a slightly newer version of master ... on the
   previous openSUSE release, and the cursor behaves normally WRT
   focus-in/out . . .

Minutes after I sent this email, I saw the bug rear its head in openSUSE
Leap 15.3.  To test, I had three instances, two with my initializations,
and one "emacs -Q".  Pretty much the only thing I did after sending the
email was to quit the "emacs -Q" and fire up another instance as root
(su and then "emacs &"), but curiously only one of the two instances
(the second one launched) was affected.  So I ran the following
augmented code in both the new root and the affected instance to see
what was going on:

	(defvar rgr-event-count 0)
	(defun rgr-focus-in ()
	  (interactive)
	  (message "focus in %d" (cl-incf rgr-event-count)))
	(define-key special-event-map [ focus-in ] 'rgr-focus-in)
	(defun rgr-focus-out ()
	  (interactive)
	  (message "focus out %d" (cl-incf rgr-event-count)))
	(define-key special-event-map [ focus-out ] 'rgr-focus-out)

As expected, the affected instance saw no in/out events, but the root
instance saw a single focus-out event when the other window caught the
focus, then a quick in/out/in sequence when the focus came back.  (I had
also seen this odd triplet when debugging under openSUSE Leap 15.4, but
at a higher level in the cursor blinking code, so I didn't mention it in
the initial bug report, thinking it might be a separate bug.)

					-- Bob

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Lars Ingebrigtsen]

Now I'm seeing this phenomenon, too, but I don't have a recipe to
reproduce it either.  But this Emacs has two frames, and if I select one
of the frames, and then select a frame from a different Emacs that
covers this frame, then both the other Emacs and this Emacs has a
blinking cursor.

If I select the frames in a different sequence, then the non-selected
Emacs frame stops blinking.

So it seems like there some sort of interaction between frames being
hidden and frames not noticing that they've lost focus?  But I'm unable
to reproduce this from "emacs -Q".

I've added Po Lu to the CCs; perhaps he has some comments here.  In
particular -- have there been any changes in the code that notices
getting/losing focus lately?

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Now I'm seeing this phenomenon, too, but I don't have a recipe to
> reproduce it either.  But this Emacs has two frames, and if I select one
> of the frames, and then select a frame from a different Emacs that
> covers this frame, then both the other Emacs and this Emacs has a
> blinking cursor.
>
> If I select the frames in a different sequence, then the non-selected
> Emacs frame stops blinking.
>
> So it seems like there some sort of interaction between frames being
> hidden and frames not noticing that they've lost focus?  But I'm unable
> to reproduce this from "emacs -Q".
>
> I've added Po Lu to the CCs; perhaps he has some comments here.  In
> particular -- have there been any changes in the code that notices
> getting/losing focus lately?

Yes -- only under the GTK 3 and no toolkit builds, where the focus code
was rewritten from scratch in order to not crash under X environments
with multiple pointers.

I will look into this, thanks.

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Yes -- only under the GTK 3 and no toolkit builds, where the focus code
> was rewritten from scratch in order to not crash under X environments
> with multiple pointers.

I'm seeing this in under Gtk3 and with a Gtk toolkit (in both of the
Emacs instances), so perhaps it's not related.

> I will look into this, thanks.

Thanks.

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Thanks.

I installed something on master that should help.  (And hopefully I will
come up with a fix for the X server too, but that might take a while.)

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> Thanks.
>
> I installed something on master that should help.  (And hopefully I will
> come up with a fix for the X server too, but that might take a while.)

I'm still seeing the problem after the update.  This is with:

In GNU Emacs 29.0.50 (build 39, x86_64-pc-linux-gnu, GTK+ Version
 3.24.33, cairo version 1.16.0) of 2022-09-03 built on joga
Repository revision: 91ba20fff159cc88c87e09f5a8256d6412c98990
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Ubuntu 22.04.1 LTS

Configured using:
 'configure -C'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

And I now have a semi-reliable way to reproduce it.

emacs -Q
C-x 5 2

Then start another Emacs, and place that frame over frame 2.  Then give
frame 2 focus.  Then switch to the other Emacs (which is covering frame
2).  Then click on the title bar of frame 1.  Both frame 1 and the other
Emacs then have blinking cursors.

This is with Gnome Shell.

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> And I now have a semi-reliable way to reproduce it.
>
> emacs -Q
> C-x 5 2
>
> Then start another Emacs, and place that frame over frame 2.  Then give
> frame 2 focus.  Then switch to the other Emacs (which is covering frame
> 2).  Then click on the title bar of frame 1.  Both frame 1 and the other
> Emacs then have blinking cursors.
>
> This is with Gnome Shell.

I tried several times (also on GNOME Shell), but it didn't work.  So if
frame 2 means the frame that was created by C-x 5 2, I still can't
reproduce this, sorry.

Could you please add instrumentation to x_focus_changed, like this:

static void
x_focus_changed (int type, int state, struct x_display_info *dpyinfo, struct frame *frame,
		 struct input_event *bufp)
{
  fprintf (stderr, "x_focus_changed: %d %d %p %p\n", type, state, frame,
	   dpyinfo->x_focus_frame);

and also instrumentation to xi_handle_focus_change, like so:

	}
    }

  fprintf (stderr, "xi_handle_focus_change: %p %p\n", <== add this instrumentation
	   new, focus);                               <==

  if (new != focus && focus)
    {
#ifdef HAVE_X_I18N
      if (FRAME_XIC (focus))
	XUnsetICFocus (FRAME_XIC (focus));
#endif

and show what is printed once the cursor begins to blink in both frames?
Thanks.

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> I tried several times (also on GNOME Shell), but it didn't work.  So if
> frame 2 means the frame that was created by C-x 5 2, I still can't
> reproduce this, sorry.

Just to make sure -- I had two different Emacses open; one with two
frames and one with a single frame in this scenario.

> and show what is printed once the cursor begins to blink in both frames?
> Thanks.

This is what the one with two frames says:

xi_handle_focus_change: (nil) 0x55bb4bd32300
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x55bb4c3ffdd0 (nil)
xi_handle_focus_change: 0x55bb4c3ffdd0 0x55bb4c3ffdd0
xi_handle_focus_change: (nil) 0x55bb4c3ffdd0
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x55bb4c3ffdd0 (nil)
xi_handle_focus_change: 0x55bb4c3ffdd0 0x55bb4c3ffdd0
xi_handle_focus_change: 0x55bb4c3ffdd0 0x55bb4c3ffdd0
xi_handle_focus_change: 0x55bb4c3ffdd0 0x55bb4c3ffdd0
xi_handle_focus_change: (nil) 0x55bb4c3ffdd0
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x55bb4bd32300 (nil)
xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
xi_handle_focus_change: (nil) 0x55bb4bd32300
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x55bb4bd32300 (nil)
xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
xi_handle_focus_change: (nil) 0x55bb4bd32300
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x55bb4c3ffdd0 (nil)
xi_handle_focus_change: 0x55bb4c3ffdd0 0x55bb4c3ffdd0
xi_handle_focus_change: (nil) 0x55bb4c3ffdd0
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x55bb4c3ffdd0 (nil)
xi_handle_focus_change: (nil) 0x55bb4c3ffdd0
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x55bb4c3ffdd0 (nil)
xi_handle_focus_change: (nil) 0x55bb4c3ffdd0
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x55bb4c3ffdd0 (nil)
xi_handle_focus_change: 0x55bb4c3ffdd0 0x55bb4c3ffdd0
xi_handle_focus_change: 0x55bb4c3ffdd0 0x55bb4c3ffdd0
xi_handle_focus_change: (nil) 0x55bb4c3ffdd0
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x55bb4bd32300 (nil)
xi_handle_focus_change: (nil) 0x55bb4bd32300
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x55bb4bd32300 (nil)
xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
xi_handle_focus_change: (nil) 0x55bb4bd32300

And this is what the other Emacs, with one frame, says:

xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x559640421300 (nil)
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: (nil) 0x559640421300
xi_handle_focus_change: 0x559640421300 (nil)
xi_handle_focus_change: (nil) 0x559640421300
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x559640421300 (nil)
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: (nil) 0x559640421300
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x559640421300 (nil)
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: (nil) 0x559640421300
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: (nil) (nil)
xi_handle_focus_change: 0x559640421300 (nil)
xi_handle_focus_change: (nil) 0x559640421300
xi_handle_focus_change: 0x559640421300 (nil)
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300
xi_handle_focus_change: 0x559640421300 0x559640421300

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> xi_handle_focus_change: 0x55bb4bd32300 (nil)
> xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
> xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
> xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
> xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
> xi_handle_focus_change: 0x55bb4bd32300 0x55bb4bd32300
> xi_handle_focus_change: (nil) 0x55bb4bd32300

This looks fine, so far.

> And this is what the other Emacs, with one frame, says:

[...]

> xi_handle_focus_change: 0x559640421300 0x559640421300
> xi_handle_focus_change: 0x559640421300 0x559640421300
> xi_handle_focus_change: 0x559640421300 0x559640421300
> xi_handle_focus_change: 0x559640421300 0x559640421300
> xi_handle_focus_change: 0x559640421300 0x559640421300
> xi_handle_focus_change: 0x559640421300 0x559640421300
> xi_handle_focus_change: 0x559640421300 0x559640421300
> xi_handle_focus_change: 0x559640421300 0x559640421300
> xi_handle_focus_change: 0x559640421300 0x559640421300

Was this printed immediately after you switched to frame 1 (on the Emacs
that has two frames)?  Or did you give the focus back to the other Emacs
(the one with a single frame) afterwards?

If the former is the case, could you please in addition to the earlier
instrumentation also instrument xi_focus_handle_for_device like such:

    case XI_FocusIn:
      device->focus_frame = mentioned_frame;
      device->focus_frame_time = event->time;

      fprintf (stderr, "XI_FocusIn\n"); <== add instrumentation here
      break;

    case XI_FocusOut:
      device->focus_frame = NULL;

      fprintf (stderr, "XI_FocusOut\n"); <== here
      break;

    case XI_Enter:
      if (!event->focus)
	break;

      if (device->use == XIMasterPointer)
	device = xi_device_from_id (dpyinfo, device->attachment);

      if (!device)
	break;

      device->focus_implicit_frame = mentioned_frame;
      device->focus_implicit_time = event->time;
      fprintf (stderr, "XI_Enter\n"); <=== here
      break;

    case XI_Leave:
      if (!event->focus)
	break;

      if (device->use == XIMasterPointer)
	device = xi_device_from_id (dpyinfo, device->attachment);

      if (!device)
	break;

      device->focus_implicit_frame = NULL;
      fprintf (stderr, "XI_Leave\n"); <=== and here
      break;

and show what is printed in the second Emacs (with a single frame) once
it starts to blink despite not being focused?

Thanks.

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I figured out how to reproduce the problem.  You have to keep the mouse
pointer inside the first frame while opening the second Emacs.  Then,
the focus sticks on the first frame because the X server totally messes
up reporting of XI_Leave events if the window manager does not set the
focus specifically on the client pointer (which the documentation is
adamant that you _can_ omit, so this is yet another X server bug.)

I installed a workaround on master.  It would be nice if all the people
who use Emacs without a window manager tried it out as well to see if it
leads to any unpleasant side effects, which it probably will, but I
don't know yet know what side effects there will be.

Thanks.

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> I installed a workaround on master.

Thanks; I can confirm that I can no longer reproduce the problem.

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> I installed a workaround on master.
>
> Thanks; I can confirm that I can no longer reproduce the problem.

Great!  If Bob says the same thing, I'll close this bug.

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Bob Rogers]

   From: Po Lu <luangruo@yahoo.com>
   Date: Sat, 03 Sep 2022 21:54:11 +0800

   Lars Ingebrigtsen <larsi@gnus.org> writes:

   > Po Lu <luangruo@yahoo.com> writes:
   >
   >> I installed a workaround on master.
   >
   > Thanks; I can confirm that I can no longer reproduce the problem.

   Great!  If Bob says the same thing, I'll close this bug.

Seems to work here.  Thanks a bunch, guys; this was driving me nuts.

					-- Bob

bug#57468: 29.0.50; Text cursor continues to blink when frame loses focus

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Bob Rogers <rogers@rgrjr.com> writes:

> Seems to work here.  Thanks a bunch, guys; this was driving me nuts.

Thanks, closing.