[qubes-users] Q4.1 xfce - "clicks in the void"

haaber · June 5, 2023, 10:39am

I often experience clicks that get lost "in the void" meaning that the
actual xfce windows does not seem to receive them.

Typical example: I use firefox, and a noscript pop-up ("load
anonymously") with a button to click on: but I can't. What helps then,
is changing the virtual screen (go away) and coming back: after this,
the click arrives again at the destination window. Very annoying!

Am I alone with this problem??? Best, Bernhard

Dan_Krol · June 5, 2023, 6:13pm

I noticed something like this but I think it’s usually triggered by something in dom0. Most notably I have a finicky power button and I get the reset/logout/shutdown dialog. When I hit escape to make it go away, I have to change virtual screens back and forth as you described.

adw · June 6, 2023, 4:59pm

There's a longstanding bug where certain types of windows sometimes can't be clicked until focus is removed from that window, then given back again. I usually alt+tab to another window, then back to the original window to fix this. I'm not sure if you're experiencing the same thing, but it sounds similar. Also, I'm not sure if this is the right issue for what I'm describing, but it seems to fit:

github.com/QubesOS/qubes-issues

window focus issue

opened 04:27PM - 31 Oct 17 UTC

raffaeleflorio

T: bug C: gui-virtualization P: major diagnosed pr submitted fixed-by-wayland

#### Qubes OS version:  R3.2 #### Affected TemplateVMs:  fedora-25 --- ### Steps to reproduce the behavior: Every program should be opened in the same qube. A real world effect is reached in this way: 1. Open two terminals. 2. Hook one terminal to the left, and one to the right. They should be on the same workspace only for comfort. 3. Go to another workspace. 4. Open some webpage and maximize it. 5. Remember a link's position. 6. Focus the terminal that doesn't cover the link position. 7. Focus the browser. 8. Go to the terminal's workspace. 9. Click on link's position in the terminal that covers it. 10. In the webpage the link is clicked. **UPDATE 1** With xev: 1. Open two terminals. 2. Hook one terminal to the left, and one to the right. They should be on the same workspace only for comfort. 3. Open xev with one terminal. 4. Move xev in another workspace. 5. Maximize xev. 6. Move to the terminal's workspace. 7. Move the mouse on the terminals. 8. Xev receives input. **UPDATE 2** Stolen keyboard input: 1. Open two terminals. 2. Hook one terminal to the left, and one to the right. They should be on the same workspace only for comfort. 3. Open gnome-terminal (however it's not related to gnome-terminal) and echo an URL. Remember URL position. 4. Move gnome-terminal to another workspace. 5. Move to the two terminals workspace. 6. Focus the terminal that doesn't cover the URL (the right one, if ltr). 7. Focus gnome-terminal. 8. Move to the two terminals workspace. 9. CTRL+CLICK on the URL position on the unfocused terminal. 10. The URL is opened. **UPDATE 3** Stolen keyboard input can be reproduced also with browser (e.g. CTRL+CLICK on a link). Actually a previous focused program (like xev or the browser) receive input iff an unfocused window and the former overlap. Furthermore input is stolen until a click happens on the unfocused window. For example, in the first case, if the browser and the _unfocused_ terminal overlap, the click on the terminal is stolen by the browser. After that the browser cannot steal more. ### Expected behavior: Unfocused window doesn't have to get input. ### Actual behavior: Unfocused window get input. ### General notes: Thanks to secure gui, It affects only programs opened in the same VM. However it isn't related to any particular window or qube. This issue isn't related to any particular windows order. **UPDATE 4** I think that it's related to Xorg --- #### Related issues: