Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Embedded window sometimes fails to receive Focus event

Open
  • Is something wrong?
#4,789 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
linux, rust
Domain
backend, desktop

Research direction

Start by tracing the X11 focus event path in winit and how it updates the window's focused state; the report does not identify a source file or failing test. Reproduce with Alacritty 0.13.2 embedded in tabbed on X11, comparing normal and failed startups with --print-events. Done when the intermittent missing Focused(true) event is understood and a regression test covers the fix.

Written by the indexing model from the issue text.

Description

B - bug DS - x11
Description

Hello!

I'm using Alacrity inside tabbed 0.7. tabbed is a frame around other windows and adds tab management. It starts with tabbed -c k alacritty --embed.

This usually works fine, but one in five startups or so, Alacritty does not have keyboard focus. It doesn't receive input and Alacritty's cursor indicates it not having focus. Despite the fact that the tabbed window definitely has focus.

  • Clicking inside alacritty with the cursor does not help.
  • Focusing Alacritty with xdotool windowfocus <id> does not help (and the focus attempt is not logged with --print-events)
  • Focusing the tabbed frame itself (with xdotool) helps
  • Focusing another window first and then moving focus back to tabbed also helps.

Normal startup logged with --print-events:

[0.139547002s] [INFO ] [alacritty] winit event: WindowEvent { window_id: WindowId(WindowId(234881029)), event: Ime(Enabled) }
[0.139798660s] [INFO ] [alacritty] winit event: WindowEvent { window_id: WindowId(WindowId(234881029)), event: Focused(false) }
[0.140879751s] [INFO ] [alacritty] winit event: WindowEvent { window_id: WindowId(WindowId(234881029)), event: Focused(true) }

Bugged startup:

[0.141411534s] [INFO ] [alacritty] winit event: WindowEvent { window_id: WindowId(WindowId(234881029)), event: Ime(Enabled) }
[0.141826159s] [INFO ] [alacritty] winit event: WindowEvent { window_id: WindowId(WindowId(234881029)), event: Focused(false) }

It would appear that there is a race condition or something inside Alacritty/winit that prevents it from receiving the Focused(true) event, and thus the internal state disagrees with the actual state, breaking keyboard focus.

OS and window mananger

Ubuntu Linux 24.04.5 LTS, X11, Xfwm4-4.18.0

Winit version

winit-0.29.15 inside Alacritty 0.13.2

Dominant language
Rust
Stars
6.2k
Forks
1.5k
Avg merge
4d 16h
Merged PRs (30d)
16

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rust-windowing/winit

All issues in rust-windowing/winit

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.