[BUG] Activated state events received for background windows when clicking title bars

[RedBearAK]

I just got finished adapting a Python script, that had been working correctly with the first iteration of the zcosmic_toplevel_info_v1 interface, to use the newly updated version 2 (of the same interface). The purpose of the script is to show debugging info about the current list of running toplevel application windows, and to print out the app class and title of the "active" window that has the keyboard focus.

The output updates as the focused window changes, by being subscribed to title, app_id, closed and state events, and keeping track of the last "handle" that had an activated state event. The "foreign toplevel" and "cosmic toplevel" handles are linked so that the events coming from zcosmic_toplevel_info_v1 and ext_foreign_toplevel_list_v1 are always being applied to the same "object" in the Python dictionary where I track the states.

Getting the active window seemed pretty simple and reliable with the version 1 cosmic_toplevel_info_unstable_v1 protocol. But now with version 2 of the protocol and the current state of the compositor, I'm seeing something pretty odd happen with extra activated state events.

If I just Alt+Tab between windows, the debugging output shows that the active window class and title are picked up as expected. However, when I click on the window's title bar, the info in the terminal in the background shows that there was a state event that caused the script to set the window behind that window as the "activated" window.

Sometimes, I have to start dragging the window before this happens.

The window that gets seen as "active" by the script is always the one right behind the window that actually has the focus. (In the apparent stacking order as seen on the screen.)

Clicking elsewhere in the window to change the focus to a new window, other than the title bar, shows the correct window being seen as "active". But as soon as I click on the title bar or try to drag the window, then the apparent "active" window becomes the background window again. The only other way to fix it is to do Alt+Tab task switching to another window and back. This triggers another "activated" state event for the foreground window, as each window is given the focus.

I don't think my script is doing anything wrong, at this point. It's already filtering out some strange "empty" state events, and state events that are just arrays of four zero (x00) values. So I'm pretty sure I'm looking at some sort of bug with a stray "activated" state event for the wrong window in the stack.

The development form of the script to query the Wayland interface is here, if anyone is interested. Other than this odd "activated" state problem, it's working as intended.

https://github.com/RedBearAK/toshy/blob/dev_beta/wlroots-dev/query_cosmic_topl_mgmt_protocol.py

Obviously if there is a bug (in the compositor) causing this, it's going to mess with any kind of applet that might be highlighting the active application. In my case the knowledge of the active window class and title allows a keymapper to apply modifier remaps and shortcut remaps in an app-specific manner. Having the wrong app window perceived as "active" will trigger the wrong keymaps and/or modmaps and make the keymapper fairly useless until a fix or solution is found.

[RedBearAK]

Another thing that fixes the problem of the wrong window being seen as "active" is interacting with the maximize button. Either maximizing or unmaximizing will fix the "active" app info. Unlike clicking on the rest of the title bar, and dragging the window.

However I've noticed that a "zero values" event happens independently of other events, if the focus is moving from a maximized window to a non-maximized window, or a maximized window is being restored to an unmaximized state. These events are confusing since a zero value would normally be interpreted as an event saying the window is maximized. But when you maximize the window you instead get a combined "maximized/activated" event.

So I decided to filter out the lone "zero values" event, just like the empty bytes value events.

[git-f0x]

Seems possibly related to #453.

[RedBearAK]

@git-f0x

Indeed, it does. And although there are two different claimed fixes, it is definitely not fixed yet. Thanks for the link.

[RedBearAK]

This issue is still present after getting the alpha 5 packages on a Fedora 41 test VM.

Edit: I see the 453 issue has been moved to alpha 7.