Urgency/focus issue in Emacs-Sway interaction (XWayland)

[thblt]

• Sway Version: 1.6 (on NixOS unstable)

• Debug Log: https://paste.thb.lt/1619006096.log.html

  • Notice I had to killall sway beause I don't know the default quit binding (I reproduced without config). If this shows in the log, it can be ignored.

• Configuration File: None (removed before reproducing)

Description

Summry

In Emacs, programmatically creating a new Emacs window and focusing back the original one creates a weird focus/urgency situation where the focused window appears urgent and the other window focused.

Steps to reproduce

In Emacs, eval the following snippet (If you don't know how to use Emacs, see the "appendix" below)

(let ((old-frame (selected-frame)) ; Store the current window (= frame, in Emacs speech)
      (new-frame (make-frame))) ; Make a new window
  (set-frame-parameter old-frame 'background-color "blue") ; Make the "old" frame blue
  (set-frame-parameter new-frame 'background-color "yellow") ; Make the "new" frame yellow
  (select-frame-set-input-focus old-frame)) ; Select back the old frame

In i3, the result is as expected: there are two emacs windows, but the focus remains as it was to the original window. In Sway, the following appears:

• Old/blue window appears as urgent (with a red border)
• New/yellow window appears focused (blue border)
• Old/blue window is the one that actually receives input.
• Moving back and forth to the old window removes the "urgent" (red border) look.

I've dug in the Emacs source code and played with xprop, and I don't believe anything there marks frames as needing attention.

Appendix: evaluating elisp code in Emacs

• Start Emacs. I assume you don't have an Emacs config; if you do, start emacs -Q to prevent loading it.
• On the Buffers menu, select *scratch* This shows a buffer starting with the commented-out message ;; This buffer is for text that is not saved….
• Make sure the cursor is at the end of the buffer, then in the Edit menu, Paste the snippet (Notice paste is Ctrl-y, not Ctrl-V)
• The buffer should still be at the end of the buffer. In the Lisp Interaction menu, choose Evaluate defun.
• Observe :)

[thblt]

This doesn't appear if the first window is focused back with swaymsg [con_id=x] focus;.

[emersion]

By default, new windows gain focus. See the no_focus directive.

[thblt]

@emersion Thank you, but I don't believe that's the issue. Unless you're saying clients should not grab focus for themselves?

FWIW, I have a workaround for my use case.

[thblt]

Just in case, this is what Emacs uses to focus one of its frames (src/xterm.c:11650)

/* In certain situations, when the window manager follows a
   click-to-focus policy, there seems to be no way around calling
   XSetInputFocus to give another frame the input focus .

   In an ideal world, XSetInputFocus should generally be avoided so
   that applications don't interfere with the window manager's focus
   policy.  But I think it's okay to use when it's clearly done
   following a user-command.  */

static void
x_focus_frame (struct frame *f, bool noactivate)
{
  Display *dpy = FRAME_X_DISPLAY (f);

  block_input ();
  x_catch_errors (dpy);

  if (FRAME_X_EMBEDDED_P (f))
    {
      /* For Xembedded frames, normally the embedder forwards key
	 events.  See XEmbed Protocol Specification at
	 https://freedesktop.org/wiki/Specifications/xembed-spec/  */
      xembed_request_focus (f);
    }
  else
    {
      XSetInputFocus (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
		      RevertToParent, CurrentTime);
      if (!noactivate)
	x_ewmh_activate_frame (f);
    }

  x_uncatch_errors ();
  unblock_input ();
}