cosmic-comp
cosmic-comp copied to clipboard
pop-os
Previously focused app takes focus while the currently focused app is grabbed
The active hint doesn't move, but the previous app becomes visibly focused when the current app is grabbed. When e.g. the search bar in Firefox is selected, and then switching to another app and grabbing it, typing while the window is grabbed will input text to the Firefox search bar.
fixed by https://github.com/pop-os/cosmic-comp/commit/d4926c3a9e66a2b699fbe626b2609ed5d373cce4
I'm still having this issue on master.
Which distro? Which commit exactly?
I'm still having this issue on master.
Which distro? Which commit exactly?
pop_OS! I added popdev:master to the sources and the system is fully up to date
I just realized that it doesn't happen when you drag the title bar, but it still happens when you drag the window while holding the Super key.
I can kind of reproduce it if the previously focused app is a GTK app (that app visually changes when the currently focused one is dragged), but doesn't have any usability issues (e.g. text input). It's just a visual issue.
I can kind of reproduce it if the previously focused app is a GTK app (that app visually changes when another is dragged), but doesn't have any usability issues (e.g. text input). It's just a visual issue.
I still have this issue with all kinds of apps, including libcosmic apps and I can still input to the background window if holding the Super key to drag. If dragging the title bar I only have this visual issue with GTK apps.
I can reproduce the visual changes in most apps with Super dragging, but text input doesn't go through. Edit: Ah, you can let go of the Super key after the drag is started, and then text input does go through.
I just realized that it doesn't happen when you drag the title bar, but it still happens when you drag the window while holding the Super key.
Oh thanks, that is what I was missing here. Reopening.
Fixed by https://github.com/pop-os/cosmic-comp/commit/6c517bd8de9e4de74a24866c274b2e1c8ac6d7e1
It's mostly fixed now, but there are still a few quirks. For example, if you drag a window (using either the title bar or the Super key) and press Super + Q, it closes the window in the background instead of the one you're dragging. This also happens with other window shortcuts like maximize.
I also noticed a minor bug(?) with input while dragging. When you long-press a key in an input field it behaves differently if you're dragging the window. Normally long key presses make the input repeat, but if you're dragging it doesn't unless you press it for long enough then the input repeats for a second or two and then it stops again. It's a bit weird and I'm not sure if this is intended or not. It's not anything major and should not affect users negatively anyways.
Some visual issues that might point to some unexpected behavior: If the previously focused app is a GTK app or an app using SSDs, it changes to visually focused when the currently focused app is dragged (Qt doesn't seem to be affected). Regardless of the toolkit/app, the App Tray highlight switches to the previously focused app during the drag. This might also be related to how Brodie managed to move both the current and the previously focused app at once between workspaces.
Another bug:
If I SUPER + Left Click some apps to drag them they will register the left click input. This doesn't affect libcosmic apps and I don't think it affects libadwaita apps as well, but it does affect kitty terminal and the non-libadwaita version of Nautilus of Pop!_OS 22.04. Probably other apps too.
That's a different issue, and not related to this. It would probably be better to add that comment to #544 (since Nautilus in 24.04 isn't affected anymore, which might be helpful).
As of today I have the latest state of COSMIC available on the Pop!_OS 24.04 LTS alpha 2 ISO (plus updates), and also whatever the latest version of things is on Fedora with the ryanabx COSMIC Epoch COPR repo.
I have a Python-based test script that uses pywayland to bind to the relevant protocols and receive events about all the "toplevel" window entities.
As described in issue #892, after converting the script from working with the version 1 COSMIC toplevel info protocol to working with the new version 2 protocol, I've been seeing activated state events for the window just below the focused window, when clicking (sometimes, mostly with non-COSMIC apps) on the title bar, and when dragging (always, especially with COSMIC apps) the window by the title bar. These erroneous activated state events cause the Python script to say that the window behind the focused window actually is the "active" window.
When looking at the debugging logging from the script, there will be a new activated state event combined with a maximized (or lack thereof) state event whenever the maximize button is toggled, so that is one way of "fixing" the script's broken awareness of the "active" window info. Another way is clicking somewhere in another window other than the title bar, and clicking back in the original window, or doing the usual Alt+Tab window switching operation.
The keyboard focus itself or "Close window" shortcut does not appear to go to the background window, in my case. Even while dragging.
Super+drag from anywhere in the window also messes up the "active" window information in the same way as dragging from the title bar.
Snapping operations don't fix the incorrect "active" information like the maximize button will. They don't cause any state change event, since there is no relevant state in the enum that has changed when a window is snapped or unsnapped.
<enum name="state">
<description summary="types of states on the toplevel">
The different states that a toplevel may have. These have the same
meaning as the states with the same names defined in xdg-toplevel
</description>
<entry name="maximized" value="0" summary="the toplevel is maximized" />
<entry name="minimized" value="1" summary="the toplevel is minimized" />
<entry name="activated" value="2" summary="the toplevel is active" />
<entry name="fullscreen" value="3" summary="the toplevel is fullscreen" />
<entry name="sticky" value="4" summary="the toplevel is sticky" since="2" />
</enum>
I also see a lot of empty state events, and often a separate all-zeroes event that I don't really understand the purpose of. I filter both of these types of events out and cause the Python script to ignore them.
Empty bytes objects look like this:
b''
All-zeroes bytes objects look like this:
b'\x00\x00\x00\x00'
Normally that set of four bytes would be interpreted as a maximized state event, but it happens with windows that are not maximized and comes in independently of any activated or activated and maximized events, so I really don't know what to make of it.
The Python script had been working perfectly with the earlier revision of the cosmic toplevel info protocol, and now works with the new combined protocols, other than this glitch where the wrong window is designated as activated after dragging the focused window.
