alacritty doesn't takes focus

[Magikh42]

Distribution

CachyOS

Package version

6.6.0-1.1

Graphics hardware in use

NVIDIA GeForce RTX 3070

Frequency

Always

Bug description

Before 6.6.0 Alacritty (terminal emulator) takes focus after launch
After all windows continue to takes focus as expected except Alacritty
This happens when I use the launch terminal shortcut (set to ctrl+enter) and also when launching from menu or an other terminal

Steps to reproduce

• Upgrade cinnamon / muffin to 6..6.0
• Launcg Alacritty

Expected behavior

Alacritty should take focus

Additional information

This is a muffin bug (not a cinnamon bug) because downgrading muffin solves this issue

[Loosefish]

Same thing happens for me on Arch. .xsession-errors is showing the following when starting alacritty.

Window manager warning: Window 0x4800003 has property _NET_STARTUP_ID
that was expected to have type UTF8_STRING format 8
and actually has type STRING format 8 n_items 0.
This is most likely an application bug, not a window manager bug.
The window has title="unknown" class="unknown" name="unknown"

[leigh123linux]

The issue doesn't reproduce on fedora.

$ rpm -q muffin cinnamon alacritty
muffin-6.6.0-1.fc43.x86_64
cinnamon-6.6.2-2.fc43.x86_64
alacritty-0.16.1-1.fc43.x86_64

[bluz71]

I also have an Arch Linux machine with a key-binding (Super-Enter) to launch Alacritty. I can confirm I have the same not focus issue.

If I use Gnome Terminal instead, focus is automatically gained, but not with Alacritty (0.16.1-1).

Muffin version 6.6.0-2.

I am sure this used to work, it still does on my Linux Mint 22.2 machine.

I hope either Muffin or Alacritty can be fixed since it really does effect usability.

[bluz71]

I did a ChatGPT session, and it believes that Muffin may now stricter with _NET_STARTUP_ID with respect to automatic focus?

Gnome Terminal does set a _NET_STARTUP_ID value for newly launched windows according to the xprop utility.

Alacritty does not appear to set any _NET_STARTUP_ID value at all.

Question to Muffin maintainers, is automatic focus now coupled to applications setting a _NET_STARTUP_ID value?

Apologies if this is the wrong rabbit hole to go down.

[alexeymuranov]

Same with Neovide.

[nNoidea]

Here is a workaround fix: linuxmint/cinnamon#13382 (comment)

[zackgomez]

I investigated this and found the root cause. It's an interaction between winit (the Rust windowing library used by alacritty) and a behavior change in Muffin 6.6.0.

When mapping a window, winit calls XMapWindow immediately followed by XConfigureWindow with stack_mode = Above — mimicking XMapRaised. This is redundant (new windows already appear on top), but it's been in winit for years without issue. Muffin 6.6.0 appears to have started treating this ConfigureWindow(ABOVE) as a focus-steal attempt and suppresses focus for the window.

I confirmed this with minimal X11 test windows:

• XMapWindow alone → Muffin gives focus ✓
• XMapWindow + XConfigureWindow(CWStackMode, Above) → Muffin does not give focus ✗

Building alacritty against a patched winit with the ConfigureWindow(ABOVE) removed fixes the issue completely.

This affects all applications using the winit library, not just alacritty. Filed upstream at rust-windowing/winit#4479. See also the detailed analysis at alacritty#8832.

That said, Muffin's behavior here seems overly aggressive — a ConfigureWindow(ABOVE) on a newly mapped window isn't really a focus-steal, and other window managers (Mutter, KWin, bspwm, Hyprland) handle it fine.

[zackgomez]

Traced the muffin-side regression to commit 3a8367f ("[Wayland] Implement xdg-activation-v1 protocol"), which added meta_window_flush_calc_showing(window) to the top of meta_window_raise().

Mechanism:

When a client (e.g. winit/alacritty) sends MapWindow followed by ConfigureWindow(stack_mode: Above):

1. MapRequest → MetaWindow created, CALC_SHOWING queued to idle
2. ConfigureRequest → stacking check passes (new window's net_wm_user_time is set to current time at construction, so XSERVER_TIME_IS_BEFORE returns FALSE) → restack_window → meta_window_raise
3. 6.6.0: meta_window_raise calls flush_calc_showing, which synchronously fires meta_window_show(), consuming the one-shot showing_for_first_time flag during ConfigureRequest processing. This disrupts the normal focus-on-map path.
4. 6.4.1: meta_window_raise just adjusted stacking. The idle fired later, meta_window_show() ran in the normal context, and focus was granted.

Potential fix:

Skip the flush for X11 windows entirely. The flush was added for Wayland xdg-activation and isn't needed for X11 (it never existed before 6.6.0):

  if (window->client_type != META_WINDOW_CLIENT_TYPE_X11)
    meta_window_flush_calc_showing (window);

This preserves the Wayland xdg-activation behavior while fixing X11 focus-on-map for windows that receive a ConfigureRequest before their initial CALC_SHOWING idle fires.

[zackgomez]

I built a version of muffin with that fix and verified that alacritty does indeed receive focus.

[zackgomez]

I experimented in Cinnamon on Wayland- definitely still a bit rough.

what I was able to see was that alacritty did indeed grab focus under wayland.
wezterm was created as as very tiny window

[Magikh42]

I built a version of muffin with that fix and verified that alacritty does indeed receive focus.

Hello could you please share a compiled / installable version ?
Also could you make a pull request in order to have the fix in the official packages