On Thu Feb 19 15:36:44 2026 +0000, Gabriel Ivăncescu wrote:
From what I read, windows are *not* activated automatically. They receive events (ClientMessage with WM_TAKE_FOCUS, or _NET_WM_STATE, etc) and that's when they're supposed to let the WM know they want to get focus/be activated or not. And that's exactly the part that fails, because we see it's "pending" even though it's not and we return early, never letting it know we want to be activated. If we remove the entire skipping logic, then it fails for other reasons so that's not a good idea either. I then get stuff like: warn:event:handle_wm_protocols Ignoring window 0x200a4/7400001 WM_TAKE_FOCUS serial 171, event_time 5459169, foreground 0x200a4 during WM_STATE change But the point is that the pending_state should be set when we actually have a pending operation on it, not a no-op. I don't understand what sense does it make to have the pending state set to something that we haven't actually requested (and thus isn't pending)??? I forgot to mention it happens with just spawning winecfg, simplest testcase possible. It doesn't receive focus. According to ICCCM, the WM does not unilaterally activate a client window on map without the client's participation when WM_TAKE_FOCUS or similar semantics apply.
And _NET_ACTIVE_WINDOW (which is what is needed) is not assumed explicitly and has to be sent manually, but that never happens since we return early. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10133#note_129966