I’m on Qubes 4.2.4 with the default XFCE desktop environment. I’m now using Qubes as my main daily OS and I love all the new security conveniences I have, but I’ve hit an anomaly that is putting my data integrity at risk.
Occasionally during normal daily use, my mouse clicks and/or keystrokes are directed to the wrong window: I can click buttons and change data in windows that are in the background, on other virtual desktops, or minimized. It initially appeared that some of my windows were randomly freezing, but I eventually discovered that the keyboard events and mouse clicks I did in them were actually being received by some other window and were fully operative there. Given that I can’t predict what effect my inputs will have on a window I can’t see, there’s no upper limit to how much data destruction or other misbehavior this could cause if I’m unlucky.
It shows up intermittently in different places, but I can usually (~75%) reproduce it like this:
on 1st Workspace: open a Chromium window
on 2nd Workspace: open two windows: Thunar File Manager and mousepad. Click on Thunar so it has input focus and mousepad does not.
on 1st Workspace: click in the Chromium window
on 2nd Workspace: click in the unfocused mousepad window in an area that overlaps with the screen coordinates of the Chromium window in the other workspace.
If the anomaly occurs, you will notice that the mousepad window appears to be frozen. What’s more concerning is that mouse clicks in it are being sent to the Chromium window in the other workspace as if it were visible on this one: you can press buttons and control Chromium from here, despite its invisibility. It’s as if the Chromium window has refused to relinquish its foreground status and continues to act like it’s being drawn in the foreground on the visible workspace.
Only certain applications will steal input like this: VS Code, Chromium, and Veracrypt do it, but others like Thunar File Manager don’t seem to.
For the record, I have tried and never succeeded in getting this to break qube isolation: all the involved windows are always in the same qube.
I don’t know if this is an issue of Qubes, XFCE, or something else. Does anyone have any ideas?
Hi @barto, thanks for looking into this. Yes, all involved windows are always in the same qube. I specifically tried to use this behavior to escape qube isolation and I couldn’t.
I just found another simple process to produce an anomaly that seems related, and may be the same one:
In the same qube and on the same workspace, open partially overlapping windows: Thunar and Chromium(or VS Code works too)
Click on the Thunar window, bringing it in front of the Chromium window
Drag a text file from the Thunar window into the Chromium window
Observe that Chromium opens the file and Thunar remains in the foreground. However, mouse clicks in the overlapping area of the Thunar window pass to the Chromium window, allowing text selection or other actions as if Chromium is actually in front.
I had such kind of issue with xmpp client Conversations, and maybe some other. The problem seems related to to GTK programs.
A common cross qubes problem with those is that when I move the cursor over a different window, I may have tooltips of the previous GTK program being displayed. I’m not entirely sure if it only happens when I switch to a different xfce virtual desktop (so both windows are on different workspaces) or not.
I just discovered the qubes-issues repo on Github. It looks like this issue is already well-known there:
also “https ://github.com/QubesOS/qubes-issues/issues/7403” (new users aren’t allowed to do 3 links in one post, apparently)
The most recent one is from 2024 and is still open, so maybe there’s hope.
Devs: Is there anything I can do to help diagnose or fix this? I’m not a qubes expert at all, but I’m certainly motivated by the seriousness of this bug.
I did more testing; no huge revelations yet, and I couldn’t change the input-stealing behavior in any way with any XFCE settings I could find.
For anyone else struggling with this issue:
There is a simple, although tedious, workaround: A single mouse click in any qube other than the affected one (or on the desktop) will stop the input-stealing effect and return the windows to their correct behavior.
This only works if you do it before an input gets misdirected, however. If you do notice a window that appears to be frozen, check all of your other windows in the same qube to figure out where your input actually went and make sure nothing bad happened. Remember, this can redirect keyboard and mouse inputs to windows that are minimized and/or on other workspaces.
Is it possible that this tooltip problem, and the other ones reported here, are all upstream issues, not Qubes related?
I have seen “persistent tooltip” issues on Fedora with lxde, even quite recently.
I have also some memories of strange focus problems with input , and even tried different focus settings trying to avoid them, but I don’t remember all details… I believe I decided it was all related to programs trying to grab mouse and keyboard.
This can’t be an upstream issue, the bug is bypassing qubes os compartmentalization at the cursor/focus level, this is a very qubes os centric bug here.
I misunderstood - I thought it was windows inside the same VM.
Different VMs is a much bigger problem… I have disabled auto-focus for new windows because of seeing input suddenly switching to a different VM when it creates a window. Maybe it could be related…
…although the drag-and-drop must be between windows of the same one.
Just to reiterate: the effect I’m reporting here does not ever break qube isolation. All input-stealing that I have ever observed has been among windows within the same qube. In fact, I have never observed a security isolation failure in any part of qubes, and I’ve been using it as my main OS for about 3 months.
I’m encountering this input-stealing anomaly a few times a week now: I haven’t lost or corrupted any data yet but I have definitely closed some browser tabs on another desktop or done similarly disruptive things a few times. The damage done isn’t merely the disruption of the program state, it’s the workflow interruption to have to go discover where the input went and confirm that nothing permanently bad happened. I’m getting good at this.
It occurs to me that with the severity of this bug, I would expect to have heard more reports or complaints about it somewhere. Not to threadjack my own thread here, but is it possible that there are far fewer actual Qubes OS users than what is generally assumed?
)