window focus issue #3267
Labels
affects-4.1
This issue affects Qubes OS 4.1.
C: gui-virtualization
diagnosed
Technical diagnosis has been performed (see issue comments).
eol-4.1
Closed because Qubes 4.1 has reached end-of-life (EOL)
fixed-by-wayland
Bugs that would not appear if Qubes OS used Wayland instead of X11
P: major
Priority: major. Between "default" and "critical" in severity.
pr submitted
A pull request has been submitted for this issue.
T: bug
Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Comments
andrewdavidwong
added
T: bug
This was referenced Jul 14, 2018
|
I have this issue in R4.14. |
|
I think this might be a dual monitor issue. It got to a point where even on a reboot I couldn't click on the windows of one specific (debian 9) AppVM. I've turned off my 2nd monitor (in hardware, and in "Displays") and upon reboot, I can resume window focus as expected. |
|
@improvethings I have this with only one monitor enabled (either my laptop scree or an external monitor only). |
|
@improvethings @e6lk7dqzm83p try generic modesetting driver if you still experimenting the problem. |
|
Moving part of the troubleshooting performed in #3267:
To reproduce this bug in chromium: This bug does not affect firefox, which as shown below, uses a different Input Model. I'm trying to review the potential use case that are missed in QubesOS related to the ICCCM windows manager convention and verify of buggy cases are realted to a specific input focus model : |
|
Here are logs when testing with Chromium (which have focus problems) and Firefox (which does not have focus problems). |
|
Here are the logs on dom0 side (gui daemon): |
|
From what I can see:
Things that still need to be investigated and that could be the culprit:
|
|
Here is a potential workaround I found in XFCE which requires to enable focus follow mouse (which is not really what I want in my case):
Using this option, the hovered windows (eg: the console) is given proper focus before I have a chance to click on it. This avoid the focus problem described there. The behavior of the windows manager will however be slightly different there. Which makes me think that it may also be a XFCE bug or some kind of race condition between focus and click event. I also tried playing with "focus stealing prevention" but it does not seems to have any effect in my chrome use case. |
|
It may be worth checking if If you're familiar enough with X11 protocol (which I believe is already the case), then I recommend |
|
Thanks for the pointer (ha ha), I will check that. I also through of potential issue with the timestamps used in XEvents in gui-agent or gui-daemon when looking at this bug: Based on ICCCM, they often ask to avoid sending CurrentTime in focus related events which is what the gui-agent is doing everytime. |
|
I'm not so confortable with X11 (I'm just feeling in pain trying to debug that, and re-reading ICCCM hundred times). |
|
The problem with timestamps is you don't really have time of the event in VM-Xorg time units, since the event does not come from VM-Xorg initially. Maybe it is a time to re-try using XSendEvent with specific target, instead of (or in addition to?) trying to switch focus in the right order? AFAIR we're tried that before and there were some problems, but I don't remember details. The code is still there, |
|
I see that you are not using |
|
Yes, exactly. |
|
Or maybe it should be some combination - like restore |
|
Here are my random debugging attempts with x11trace |
|
Ok, so it does grab mouse pointer. |
|
So, here is the X11 events when using firefox right when I click on the overlapping terminal window with firefox focused in. We clearly see the ButtonPress event coming before FocusOut (I did not analysed the windows numbers however). Then |
|
Same for chromium, |
|
The main difference for chromium is that in a working situation ("Focus follow mouse" model), a LeaveNotify event is sent from the XServer: |
|
I think this may be related to front-back windows relation on the VM side. It is very hard to get them in sync with dom0. We workaround this by bringing window to front whenever it should receive focus. This works fine with "focus follow mouse", because focus is given before the click. But if focus is given on click, order of those events may be swapped (as click and XRaiseWindow are delivered to X server through different channels). Since fixing #4351 you can actually take a look how it is on the VM side, by using x11vnc + vncviewer locally in that VM. One possible fix would be to bring a window to front not only when it gets focus, but also when mouse enters its region (see Ideally, windows ordering on the VM side should be the same as in dom0... |
andrewdavidwong
added
needs diagnosis
|
Cannot reproduce under this branch, which treat all focus events equally. |
DemiMarie
added
the
fixed-by-wayland
DemiMarie
added a commit
to DemiMarie/qubes-gui-agent-linux
that referenced
this issue
Aug 23, 2022
Events from the GUI daemon are directed at specific windows. Ensuring that they are sent to the correct window is more importent than obeying the ICCCM input hint. Giving pointer focus to a window is accomplished by raising it. Fixes QubesOS/qubes-issues#3267.
DemiMarie
added
diagnosed
andrewdavidwong
added
the
eol-4.1
|
This issue is being closed because:
If anyone believes that this issue should be reopened, please leave a comment saying so. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
UPDATE 1
With xev:
UPDATE 2
Stolen keyboard input:
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:
The text was updated successfully, but these errors were encountered: