Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Sub windows in java applications close immediately #3982

Closed
thewildcat opened this issue Jun 12, 2018 · 44 comments · Fixed by QubesOS/qubes-gui-agent-linux#124
Closed

Sub windows in java applications close immediately #3982

thewildcat opened this issue Jun 12, 2018 · 44 comments · Fixed by QubesOS/qubes-gui-agent-linux#124
Labels
C: gui-virtualization diagnosed Technical diagnosis has been performed (see issue comments). P: critical Priority: critical. Between "major" and "blocker" in severity. r4.0-bullseye-stable r4.0-buster-stable r4.0-centos7-stable r4.0-centos8-stable r4.0-fc31-stable r4.0-fc32-stable r4.0-fc33-stable r4.0-stretch-stable r4.1-bullseye-stable r4.1-buster-stable r4.1-centos8-stable r4.1-dom0-stable r4.1-fc31-stable r4.1-fc32-stable r4.1-fc33-stable T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Milestone
Release 4.0 updates

Comments

@thewildcat
Copy link

thewildcat commented Jun 12, 2018 •
edited
Loading

Qubes OS version:

R3.2 with xfce

Affected component(s):

Window manager maybe?

Steps to reproduce the behavior:

Download the latest intellij rider:
https://www.jetbrains.com/rider/
Try to open submenus like right clicking inside the editor window (the submenu instantly closes).
Also effects burp suite:
https://portswigger.net/burp/releases/download?product=community&version=1.7.33&type=jar
Try to open any help menu, it instantly closes.

Expected behavior:

The sub window should stay open.

Actual behavior:

The window closes directly

General notes:

It is not a recent change in the JVM code, I tried old versions from OpenJDK and Oracle (7,8,9) same issue. It must be some java user code that triggers it.

The question is, can this be addressed in qubes as well? Some issue within the window manager?

Related issues:

https://support.portswigger.net/customer/en/portal/questions/17346734-burp-overlay-menus-no-longer-working-on-fedora-26
@pgerber
Copy link

pgerber commented Jun 12, 2018

I reported a bug against InteliJ IDEA describing this issue a while back. Doesn't appear to be Qubes-specific, users of many other distros are affected too.

@andrewdavidwong
Copy link
Member

Closing as "not our bug." If you believe this is a mistake, please leave a comment, and we'll be happy to take another look. Thank you.

@andrewdavidwong andrewdavidwong added the R: upstream issue Resolution: This issue pertains to software that the Qubes OS Project does not develop or control. label Jun 13, 2018
@thewildcat
Copy link
Author

That may be true for IntelliJ, but with burp I have not been able to reproduce it on any other distribution or system other than Qubes R3.2 (see my comments from the burp bug report).

As I am working in the infosec business, this tool is quite essential from time to time. I'll have to test if it also effects Qubes 4.0 if not, the switch is planned for this year anyway.

@andrewdavidwong andrewdavidwong added T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. C: gui-virtualization and removed R: upstream issue Resolution: This issue pertains to software that the Qubes OS Project does not develop or control. labels Jun 14, 2018
@andrewdavidwong andrewdavidwong added this to the Release 3.2 updates milestone Jun 14, 2018
@ptitdoc
Copy link

ptitdoc commented Jul 19, 2018

In burp under QubesR4 (archlinux template) I also observe similar problem with the proxy history filter panel.

I have not been able to investigate the reason yet but a similar issue encountered in Qubes 3.0 was tracked down to a missing implementation of some X11 protocol feature within qubes GUI code.

@ptitdoc
Copy link

ptitdoc commented Jul 19, 2018

Do you know a very minimal Java program that highlight this issue ? This would help a lot for troubleshooting.

@netmackan
Copy link

netmackan commented Jul 20, 2018 •
edited
Loading

I have a minimal Java application showing a possibly similar issue that I had with NetBeans IDE where some windows where loosing focus sometimes and thus being closed only when running with Qubes:
https://github.com/netmackan/qubes-java-focus-issue

Anyway I just run it and it is still reproducible in 4.0.

Updated: to clarify that I am not sure this is the same issue.

@thewildcat
Copy link
Author

This issue also effects Qubes 4.0.

@SvenSemmler
Copy link

SvenSemmler commented Aug 27, 2018 •
edited
Loading

I am observing the same issue with TheBrain 8 on both R3.2 and on R4.0 since I use Qubes both with Xfce and also with i3.

Additional note: in my case I can sometimes get the panel to stay, by opening it rapidly over and over ... after 40+ tries is stays for that one time. Once closed, it's back to the buggy behavior.

Luckily in TheBrain this GUI element is only used to select the color for labels ... so once it's set one doesn't need it anymore. Which is why I didn't bother reporting it. But it appears based on the other mentions here that this is a general Java application issue under Qubes.

@thewildcat
Copy link
Author

Any news with this issue? As it also effects Qubes 4 and multiple java applications as it appears @andrewdavidwong ?

@andrewdavidwong
Copy link
Member

Any news with this issue? As it also effects Qubes 4 and multiple java applications as it appears

Sorry, I'm not aware of any news about this besides what's on this issue.

@nil0x42
Copy link

nil0x42 commented Dec 2, 2018

I have the same issue, with both BurpSuite & Maltego on Qubes OS R4.0

@ptitdoc
Copy link

ptitdoc commented Feb 5, 2019

Hello,
I confirmed again this issue today and tried a more thorough investigation without much success:

  • First case: qubes-java-focus-issue or burp-suite v1.6.x: when the user clicks on the menu, java opens up a new window, however the focus is lost immediately most of the time, on which case the java app hide and/or destroy the window. It sometimes keep the focus, maybe because the mouse pointer is by chance just under the newly created window, however it is hard to debug without comparing the java AWT focus handling code vs pointer positions sent by dom0. Another potential issue is a bad implementation of VM_TAKE_FOCUS (QubesOS/qubes-gui-daemon@89e1a19) however it is hard to say anything based on vmside or dom0 gui-daemon logs.
  • Second case: on burp-suite v2.x, they apparently implemented the problematic popup slightly differently and the window is not closing on focus exit, but on event where the user release click on the filter bar. This basically fixes this issue for burp-suite 2.x however the window is normally an integrated panel as shown in the screenshot (the "Filter by search term" panel), but in QubesOS it shows as a real windows with a close button. If a user click on the close button, it destroy the window definitively instead of only hiding it, which breaks the application.
    burp_filter_submenu

I will try to do additional debugging to see if the problem is related to pointer positions sent by dom0.

@andrewdavidwong andrewdavidwong added the P: major Priority: major. Between "default" and "critical" in severity. label Feb 6, 2019
@ptitdoc
Copy link

ptitdoc commented Feb 6, 2019 •
edited
Loading

  • Third case: potentially related to that is clients such as chromium that keep the focus even when clicking on another windows. This behavior is probably related even if it is not blocking. The consequence is that it makes middle-click-to-paste unusable in these circumstance because the input apparently stays on the chromium window (but i wonder if it is mouse input or keyboard input which is locked).

Edit: Case 3 Chromium discussion has been moved to #3267

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 :
https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.4
https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7

Still, these kind of problems are often related to java (AWK/Swing) and are encountered by most windows managers. Here are some potentially related references I found:
stumpwm/stumpwm#149
https://code.google.com/archive/p/xmonad/issues/177
i3/i3#578
https://github.com/Airblader/unclutter-xfixes

@ptitdoc
Copy link

ptitdoc commented Feb 7, 2019

Hello,
I tried to increase debugging on the VM side. I'm currently only investigating the First case: qubes-java-focus-issue.

Here are my attempt to open the popup (vm side logs):

# Quitting Console focus and Starting QubesJavaFocusIssue1 Focus by clicking on File menu
Feb 07 09:01:20 untrusted qubes-gui[891]: received message type 128 for 0x120002f
Feb 07 09:01:20 untrusted qubes-gui[891]: Starting handle_focus for 0x120002f key.type:10 key.mode:0
Feb 07 09:01:20 untrusted qubes-gui[891]: Window 0x120002f has inputhit set to 1 and takefocus set to 1
Feb 07 09:01:20 untrusted qubes-gui[891]: FocusOut actions for 0x120002f
Feb 07 09:01:20 untrusted qubes-gui[891]: 0x120002f lost focus
Feb 07 09:01:20 untrusted qubes-gui[891]: received message type 142 for 0x0
Feb 07 09:01:20 untrusted qubes-gui[891]: received message type 128 for 0x1000007
Feb 07 09:01:20 untrusted qubes-gui[891]: Starting handle_focus for 0x1000007 key.type:9 key.mode:0
Feb 07 09:01:20 untrusted qubes-gui[891]: Window 0x1000007 has inputhit set to 0 and takefocus set to 1
Feb 07 09:01:20 untrusted qubes-gui[891]: FocusIn actions for 0x1000007
Feb 07 09:01:20 untrusted qubes-gui[891]: WM_TAKE_FOCUS sent for 0x1000007
Feb 07 09:01:20 untrusted qubes-gui[891]: 0x1000007 raised
Feb 07 09:01:20 untrusted qubes-gui[891]: received message type 125 for 0x1000007

# Quitting Console focus and Starting QubesJavaFocusIssue1 Focus by clicking on Show Popup
Feb 07 09:02:41 untrusted qubes-gui[891]: received message type 126 for 0x1000007
Feb 07 09:02:41 untrusted qubes-gui[891]: received message type 126 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 128 for 0x120002f
Feb 07 09:02:43 untrusted qubes-gui[891]: Starting handle_focus for 0x120002f key.type:10 key.mode:0
Feb 07 09:02:43 untrusted qubes-gui[891]: Window 0x120002f has inputhit set to 1 and takefocus set to 1
Feb 07 09:02:43 untrusted qubes-gui[891]: FocusOut actions for 0x120002f
Feb 07 09:02:43 untrusted qubes-gui[891]: 0x120002f lost focus
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 142 for 0x0
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 128 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: Starting handle_focus for 0x1000007 key.type:9 key.mode:0
Feb 07 09:02:43 untrusted qubes-gui[891]: Window 0x1000007 has inputhit set to 0 and takefocus set to 1
Feb 07 09:02:43 untrusted qubes-gui[891]: FocusIn actions for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: WM_TAKE_FOCUS sent for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: 0x1000007 raised
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 125 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: send buttonevent, win 0x1000007 type=4 button=1
Feb 07 09:02:43 untrusted qubes-gui[891]: handle configure event 0x1000007 w=1091 h=849 ovr=0
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 125 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: send buttonevent, win 0x1000007 type=5 button=1
Feb 07 09:02:43 untrusted qubes-gui[891]: Create for 0x1000054 class 0x1
Feb 07 09:02:43 untrusted qubes-gui[891]: got net_wm_name=PopupWin
Feb 07 09:02:43 untrusted qubes-gui[891]: Protocol take_focus supported for Window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: handle property WM_TRANSIENT_FOR for window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: handle property WM_HINTS for window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: Received WMHints without input hint set for Window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: Create for 0x100005b class 0x1
Feb 07 09:02:43 untrusted qubes-gui[891]: got net_wm_name=sun-awt-X11-XIconWindow
Feb 07 09:02:43 untrusted qubes-gui[891]: handle property WM_HINTS for window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: Received WMHints without input hint set for Window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: handle property WM_NORMAL_HINTS for window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: handle property WM_NORMAL_HINTS for window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: handle configure event 0x1000054 w=104 h=15 ovr=0
Feb 07 09:02:43 untrusted qubes-gui[891]: handle property _MOTIF_WM_HINTS for window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: handle property WM_NORMAL_HINTS for window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: handle property WM_NORMAL_HINTS for window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: handle property WM_HINTS for window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: Received input hint 0x0 for Window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: handle configure event 0x1000054 w=104 h=15 ovr=0
Feb 07 09:02:43 untrusted qubes-gui[891]: MAP for window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: got net_wm_name=PopupWin
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 134 for 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: configure msg, x/y 104 124 (was 100 100), w/h 104 15 (was 104 15)
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 128 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: Starting handle_focus for 0x1000007 key.type:10 key.mode:0
Feb 07 09:02:43 untrusted qubes-gui[891]: Window 0x1000007 has inputhit set to 0 and takefocus set to 1
Feb 07 09:02:43 untrusted qubes-gui[891]: FocusOut actions for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: 0x1000007 lost focus
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 142 for 0x0
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 128 for 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: Starting handle_focus for 0x1000054 key.type:9 key.mode:0
Feb 07 09:02:43 untrusted qubes-gui[891]: Window 0x1000054 has inputhit set to 0 and takefocus set to 1
Feb 07 09:02:43 untrusted qubes-gui[891]: FocusIn actions for 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: WM_TAKE_FOCUS sent for 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: 0x1000054 raised
Feb 07 09:02:43 untrusted qubes-gui[891]: handle configure event 0x1000054 w=104 h=15 ovr=0
Feb 07 09:02:43 untrusted qubes-gui[891]: handle property WM_HINTS for window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: Received input hint 0x0 for Window 0x1000054
# UNMAP is called here for unknown reason
Feb 07 09:02:43 untrusted qubes-gui[891]: UNMAP for window 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 128 for 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: Starting handle_focus for 0x1000054 key.type:10 key.mode:0
Feb 07 09:02:43 untrusted qubes-gui[891]: Window 0x1000054 has inputhit set to 0 and takefocus set to 1
Feb 07 09:02:43 untrusted qubes-gui[891]: FocusOut actions for 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: 0x1000054 lost focus
Feb 07 09:02:43 untrusted qubes-gui[891]: handle destroy 0x100005b
Feb 07 09:02:43 untrusted qubes-gui[891]: handle destroy 0x1000054
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 142 for 0x0
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 128 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: Starting handle_focus for 0x1000007 key.type:9 key.mode:0
Feb 07 09:02:43 untrusted qubes-gui[891]: Window 0x1000007 has inputhit set to 0 and takefocus set to 1
Feb 07 09:02:43 untrusted qubes-gui[891]: FocusIn actions for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: WM_TAKE_FOCUS sent for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: 0x1000007 raised
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 128 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: Starting handle_focus for 0x1000007 key.type:10 key.mode:0
Feb 07 09:02:43 untrusted qubes-gui[891]: Window 0x1000007 has inputhit set to 0 and takefocus set to 1
Feb 07 09:02:43 untrusted qubes-gui[891]: FocusOut actions for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: 0x1000007 lost focus
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 142 for 0x0
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 128 for 0x120002f
Feb 07 09:02:43 untrusted qubes-gui[891]: Starting handle_focus for 0x120002f key.type:9 key.mode:0
Feb 07 09:02:43 untrusted qubes-gui[891]: Window 0x120002f has inputhit set to 1 and takefocus set to 1
Feb 07 09:02:43 untrusted qubes-gui[891]: FocusIn actions for 0x120002f
Feb 07 09:02:43 untrusted qubes-gui[891]: WM_TAKE_FOCUS sent for 0x120002f
Feb 07 09:02:43 untrusted qubes-gui[891]: 0x120002f raised
Feb 07 09:02:43 untrusted qubes-gui[891]: handle configure event 0x120002f w=1584 h=507 ovr=0
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 126 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 126 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 126 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 126 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 126 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 126 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 126 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 126 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 126 for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: received message type 126 for 0x1000007

# Top Window Focus In Logs
Feb 07 09:02:43 untrusted qubes-gui[891]: Window 0x1000007 has inputhit set to 0 and takefocus set to 1
Feb 07 09:02:43 untrusted qubes-gui[891]: Starting handle_focus for 0x1000007 key.type:9 key.mode:0
Feb 07 09:02:43 untrusted qubes-gui[891]: Window 0x1000007 has inputhit set to 0 and takefocus set to 1
Feb 07 09:02:43 untrusted qubes-gui[891]: FocusIn actions for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: WM_TAKE_FOCUS sent for 0x1000007
Feb 07 09:02:43 untrusted qubes-gui[891]: 0x1000007 raised

# Popup Creation In Logs
Feb 07 09:04:05 untrusted qubes-gui[891]: received message type 125 for 0x1000007
Feb 07 09:04:05 untrusted qubes-gui[891]: send buttonevent, win 0x1000007 type=5 button=1
Feb 07 09:04:05 untrusted qubes-gui[891]: Create for 0x100006b class 0x1
Feb 07 09:04:05 untrusted qubes-gui[891]: got net_wm_name=PopupWin
Feb 07 09:04:05 untrusted qubes-gui[891]: Protocol take_focus supported for Window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: handle property WM_TRANSIENT_FOR for window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: handle property WM_HINTS for window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: Received WMHints without input hint set for Window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: Create for 0x1000072 class 0x1
Feb 07 09:04:05 untrusted qubes-gui[891]: got net_wm_name=sun-awt-X11-XIconWindow
Feb 07 09:04:05 untrusted qubes-gui[891]: handle property WM_HINTS for window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: Received WMHints without input hint set for Window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: handle property WM_NORMAL_HINTS for window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: handle property WM_NORMAL_HINTS for window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: handle configure event 0x100006b w=104 h=15 ovr=0
Feb 07 09:04:05 untrusted qubes-gui[891]: handle property _MOTIF_WM_HINTS for window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: handle property WM_HINTS for window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: Received input hint 0x0 for Window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: handle configure event 0x100006b w=104 h=15 ovr=0
Feb 07 09:04:05 untrusted qubes-gui[891]: MAP for window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: got net_wm_name=PopupWin
Feb 07 09:04:05 untrusted qubes-gui[891]: handle property WM_NORMAL_HINTS for window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: handle property WM_NORMAL_HINTS for window 0x100006b

# Focus gets from top window to popup window
Feb 07 09:04:05 untrusted qubes-gui[891]: received message type 128 for 0x1000007
Feb 07 09:04:05 untrusted qubes-gui[891]: Starting handle_focus for 0x1000007 key.type:10 key.mode:0
Feb 07 09:04:05 untrusted qubes-gui[891]: Window 0x1000007 has inputhit set to 0 and takefocus set to 1
Feb 07 09:04:05 untrusted qubes-gui[891]: FocusOut actions for 0x1000007
Feb 07 09:04:05 untrusted qubes-gui[891]: 0x1000007 lost focus

Feb 07 09:04:05 untrusted qubes-gui[891]: received message type 128 for 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: Starting handle_focus for 0x100006b key.type:9 key.mode:0
Feb 07 09:04:05 untrusted qubes-gui[891]: Window 0x100006b has inputhit set to 0 and takefocus set to 1
Feb 07 09:04:05 untrusted qubes-gui[891]: FocusIn actions for 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: WM_TAKE_FOCUS sent for 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: 0x100006b raised
Feb 07 09:04:05 untrusted qubes-gui[891]: handle property WM_HINTS for window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: Received input hint 0x0 for Window 0x100006b
# UNMAP is called for unknown reasons
Feb 07 09:04:05 untrusted qubes-gui[891]: UNMAP for window 0x100006b
Feb 07 09:04:05 untrusted qubes-gui[891]: handle destroy 0x1000072
Feb 07 09:04:05 untrusted qubes-gui[891]: handle destroy 0x100006b

Here are the gui-daemon dom0 side logs corresponding to similar actions:

shmimage for 0x5400117(remote 0x1000007), x: 5, y: 12, w: 1, h: 1
  do_shm_update for 0x5400117(remote 0x1000007), after border calc: x=5, y=12, w=1, h=1
shmimage for 0x5400117(remote 0x1000007), x: 11, y: 34, w: 84, h: 23
  do_shm_update for 0x5400117(remote 0x1000007), after border calc: x=11, y=34, w=84, h=23
shmimage for 0x5400010(remote 0x120002f), x: 0, y: 27, w: 1584, h: 480
  do_shm_update for 0x5400010(remote 0x120002f), after border calc: x=0, y=27, w=1584, h=480
shmimage for 0x5400010(remote 0x120002f), x: 0, y: 27, w: 1584, h: 480
  do_shm_update for 0x5400010(remote 0x120002f), after border calc: x=0, y=27, w=1584, h=480
xside: win 0x5400117(0x1000007) type=4 button=1 x=59, y=49
handle_configure_from_vm, local 0x5400117 remote 0x1000007, 1091/849, was 1091/849, ovr=0, xy 910/143, was 910/143
MSG_MFNDUMP for 0x5400117(0x1000007): 1091x849, num_mfn 0x389 off 0x68
shmimage for 0x5400117(remote 0x1000007), x: 11, y: 34, w: 84, h: 23
  do_shm_update for 0x5400117(remote 0x1000007), after border calc: x=11, y=34, w=84, h=23
xside: win 0x5400117(0x1000007) type=5 button=1 x=59, y=49
# Creation of the popup window and frames ? 0x540025b(0x100008b) / 0x540025c(0x1000092)
Created 0x540025b(0x100008b) parent 0x0(0x3aa) ovr=0 x/y 100/100 w/h 1/1
set WM_NORMAL_HINTS for window 0x540025b to min=0/0, max=0/0, base=0/0, inc=0/0 (flags 0x5)
set title for window 0x540025b
set class hint for window 0x540025b to (untrusted:se-kilas-markus-qubes-qubesjavafocusissue1-MainFrame, untrusted:sun-awt-X11-XDialogPeer)
Created 0x540025c(0x1000092) parent 0x0(0x3aa) ovr=0 x/y 0/0 w/h 16/16
set title for window 0x540025c
set WM_NORMAL_HINTS for window 0x540025b to min=0/0, max=0/0, base=0/0, inc=0/0 (flags 0x5)
set WM_NORMAL_HINTS for window 0x540025b to min=0/0, max=0/0, base=0/0, inc=0/0 (flags 0x5)
handle_configure_from_vm, local 0x540025b remote 0x100008b, 104/15, was 1/1, ovr=0, xy 100/100, was 100/100

XMoveResizeWindow local 0x540025b remote 0x100008b, xy 100 100 (vm_window is 100 100) wh 104 15
process_xevent_configure(synth 0) local 0x540025b remote 0x100008b, 104/15, was 104/15, xy 100/100 was 100/100
MSG_MFNDUMP for 0x540025b(0x100008b): 1920x1200, num_mfn 0x8cb off 0x10
handle_configure_from_vm, local 0x540025b remote 0x100008b, 104/15, was 104/15, ovr=0, xy 100/100, was 100/100
MSG_MFNDUMP for 0x540025b(0x100008b): 104x15, num_mfn 0x2 off 0x458
set title for window 0x540025b
MSG_MFNDUMP for 0x540025b(0x100008b): 104x15, num_mfn 0x2 off 0x458
shmimage for 0x540025b(remote 0x100008b), x: 0, y: 0, w: 104, h: 15
  do_shm_update for 0x540025b(remote 0x100008b), after border calc: x=0, y=0, w=104, h=15
shmimage for 0x540025b(remote 0x100008b), x: 0, y: 0, w: 104, h: 15
  do_shm_update for 0x540025b(remote 0x100008b), after border calc: x=0, y=0, w=104, h=15
set WM_NORMAL_HINTS for window 0x540025b to min=0/0, max=0/0, base=0/0, inc=0/0 (flags 0x5)
set WM_NORMAL_HINTS for window 0x540025b to min=0/0, max=0/0, base=0/0, inc=0/0 (flags 0x5)
# First call to reparent on  0x100008b (dom0 parent  0x8bbc51)
process_xevent_reparent(synth 0) local 0x540025b remote 0x100008b, local parent 0x8bbc51, frame window 0x8bbc51
shmimage for 0x5400117(remote 0x1000007), x: 11, y: 34, w: 84, h: 23
  do_shm_update for 0x5400117(remote 0x1000007), after border calc: x=11, y=34, w=84, h=23
process_xevent_configure(synth 0) local 0x540025b remote 0x100008b, 104/15, was 104/15, xy 4/24 was 100/100
  translated to 104/124
shmimage for 0x540025b(remote 0x100008b), x: 0, y: 0, w: 104, h: 15
  do_shm_update for 0x540025b(remote 0x100008b), after border calc: x=0, y=0, w=104, h=15
process_xevent_configure(synth 1) local 0x540025b remote 0x100008b, 104/15, was 104/15, xy 104/124 was 104/124
  do_shm_update for 0x540025b(remote 0x100008b), after border calc: x=0, y=0, w=104, h=15
handle_configure_from_vm, local 0x540025b remote 0x100008b, 104/15, was 104/15, ovr=0, xy 104/124, was 104/124
MSG_MFNDUMP for 0x540025b(0x100008b): 104x15, num_mfn 0x2 off 0x458
shmimage for 0x540012b(remote 0x1400003), x: 100, y: 45, w: 104, h: 15
  do_shm_update for 0x540012b(remote 0x1400003), after border calc: x=100, y=45, w=104, h=15
shmimage for 0x540025b(remote 0x100008b), x: 0, y: 0, w: 104, h: 15
  do_shm_update for 0x540025b(remote 0x100008b), after border calc: x=0, y=0, w=104, h=15
shmimage for 0x540012b(remote 0x1400003), x: 104, y: 69, w: 104, h: 15
  do_shm_update for 0x540012b(remote 0x1400003), after border calc: x=104, y=69, w=104, h=15
handle_configure_from_vm, local 0x5400117 remote 0x1000007, 1091/849, was 1091/849, ovr=0, xy 910/143, was 910/143
MSG_MFNDUMP for 0x5400117(0x1000007): 1091x849, num_mfn 0x389 off 0x68
# Second call to reparent on  0x100008b (dom0 parent  0xf6 - frame 0x0 ?)
process_xevent_reparent(synth 0) local 0x540025b remote 0x100008b, local parent 0xf6, frame window 0x0
# XDestroyWindow initiated on popup (apparently coming from UNMAP initiated from the Java program)
 XDestroyWindow 0x540025c
 XDestroyWindow 0x540025b
# From there everything fails becasue the windows has been destroyed
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
shmimage for 0x5400009(remote 0x1200003), x: 0, y: 26, w: 814, h: 459
  do_shm_update for 0x5400009(remote 0x1200003), after border calc: x=0, y=26, w=814, h=459
cannot lookup 0x540025c in wid2windowdata
cannot lookup 0x540025c in wid2windowdata
cannot lookup 0x540025c in wid2windowdata
cannot lookup 0x540025c in wid2windowdata
cannot lookup 0x540025c in wid2windowdata
cannot lookup 0x540025c in wid2windowdata
cannot lookup 0x540025c in wid2windowdata
cannot lookup 0x540025c in wid2windowdata
cannot lookup 0x540025c in wid2windowdata
cannot lookup 0x540025c in wid2windowdata
cannot lookup 0x540025c in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
cannot lookup 0x540025b in wid2windowdata
shmimage for 0x5400010(remote 0x120002f), x: 0, y: 27, w: 1584, h: 480
  do_shm_update for 0x5400010(remote 0x120002f), after border calc: x=0, y=27, w=1584, h=480
shmimage for 0x5400117(remote 0x1000007), x: 11, y: 34, w: 84, h: 23
  do_shm_update for 0x5400117(remote 0x1000007), after border calc: x=11, y=34, w=84, h=23
shmimage for 0x5400010(remote 0x120002f), x: 0, y: 27, w: 1584, h: 480
  do_shm_update for 0x5400010(remote 0x120002f), after border calc: x=0, y=27, w=1584, h=480
shmimage for 0x5400010(remote 0x120002f), x: 0, y: 27, w: 1584, h: 480
  do_shm_update for 0x5400010(remote 0x120002f), after border calc: x=0, y=27, w=1584, h=480
shmimage for 0x5400117(remote 0x1000007), x: 2, y: 40, w: 1, h: 1
  do_shm_update for 0x5400117(remote 0x1000007), after border calc: x=2, y=40, w=1, h=1
shmimage for 0x5400010(remote 0x120002f), x: 0, y: 27, w: 1584, h: 480
  do_shm_update for 0x5400010(remote 0x120002f), after border calc: x=0, y=27, w=1584, h=480
handle_configure_from_vm, local 0x5400117 remote 0x1000007, 1091/849, was 1091/849, ovr=0, xy 910/143, was 910/143
MSG_MFNDUMP for 0x5400117(0x1000007): 1091x849, num_mfn 0x389 off 0x68
shmimage for 0x5400117(remote 0x1000007), x: 626, y: 3, w: 1, h: 1
  do_shm_update for 0x5400117(remote 0x1000007), after border calc: x=626, y=3, w=1, h=1
process_xevent_configure(synth 1) local 0x5400117 remote 0x1000007, 1091/849, was 1091/849, xy 922/144 was 910/143
handle_configure_from_vm, local 0x5400117 remote 0x1000007, 1091/849, was 1091/849, ovr=0, xy 922/144, was 922/144
MSG_MFNDUMP for 0x5400117(0x1000007): 1091x849, num_mfn 0x389 off 0x68
shmimage for 0x5400010(remote 0x120002f), x: 645, y: 21, w: 939, h: 1
  do_shm_update for 0x5400010(remote 0x120002f), after border calc: x=645, y=21, w=939, h=1
shmimage for 0x5400010(remote 0x120002f), x: 645, y: 22, w: 12, h: 485
  do_shm_update for 0x5400010(remote 0x120002f), after border calc: x=645, y=22, w=12, h=485
shmimage for 0x540012b(remote 0x1400003), x: 1849, y: 88, w: 71, h: 1
  do_shm_update for 0x540012b(remote 0x1400003), after border calc: x=1849, y=88, w=71, h=1
shmimage for 0x540012b(remote 0x1400003), x: 910, y: 574, w: 12, h: 363
  do_shm_update for 0x540012b(remote 0x1400003), after border calc: x=910, y=574, w=12, h=363
shmimage for 0x5400117(remote 0x1000007), x: 0, y: 0, w: 1091, h: 849
  do_shm_update for 0x5400117(remote 0x1000007), after border calc: x=0, y=0, w=1091, h=849
process_xevent_configure(synth 1) local 0x5400117 remote 0x1000007, 1091/849, was 1091/849, xy 929/145 was 922/144
handle_configure_from_vm, local 0x5400117 remote 0x1000007, 1091/849, was 1091/849, ovr=0, xy 929/145, was 929/145

@ptitdoc
Copy link

ptitdoc commented Feb 7, 2019

OK I think I found the problem related to Case 1.

Java programs are often using Globally Active Input Models, meaning that they don't care about focus and guess it themselves somehow instead of being informed by the windows manager through XSetInputFocus, however they are allowed to send TAKE_FOCUS Messages to get keystrokes or mouse events.

In our case, the qubes gui agent in vmside.c properly takes in account the fact that Globally Active Input Models should not receive XSetInputFocus events when the windows manager want to give focus to the VM. However this condition is not properly verified when the windows manager want to remove focus which means that XSetInputFocus event are sent every time the WM want to remove focus and the java program that receive this event at window creation time close the popup window immediately (because it things the focus is out of his window).

@ptitdoc
Copy link

ptitdoc commented Feb 7, 2019

if (input_hint) condition needs to be added here (however, input_hint is not populated inside this conditional branch):
https://github.com/QubesOS/qubes-gui-agent-linux/blob/130865253fe03d37cdec17c8fabdae6bbcca1354/gui-agent/vmside.c#L1647

I will test if there are border effects of this change and if it solves the other cases.

@ghost
Copy link

ghost commented Feb 7, 2019 •
edited by ghost
Loading

I have noticed this behavior in Intellij IDEA as well as BiglyBT with Qubes R4.0. Strange thing is that IDEA was working fine before.
Seems to be a regression in IDEA. Right-click menus in BiglyBT work occasionally but not always.

@ptitdoc
Copy link

ptitdoc commented Feb 8, 2019 •
edited
Loading

A remaining problem (which is a lower priority for me as it has little effect) is case2 where a java application which apparently attempt to use something similar than override redirect (a windows with no border), but Qubes creates a plain windows with close buttons. But this may be on purpose as there is an active discussion to limit override redirect windows there:
#4705

@ptitdoc ptitdoc mentioned this issue Feb 8, 2019
Closed
@marmarek marmarek mentioned this issue Oct 30, 2019
Closed
4 tasks
@marmarek marmarek mentioned this issue May 11, 2020
Closed
@somehibs
Copy link

somehibs commented Jun 17, 2020 •
edited
Loading

This issue is driving me insane. I use Qubes every day, and IntelliJ recently became unusable when I gave it more RAM and switched to i3 window manager. Even autocomplete windows immediately close themselves unless my machine is under high load. Oracle, why did you make Java so 'smart'.

@ptitdoc, is there a patch file or branch with your GUI manager changes?

@qubesos-bot
Copy link

Automated announcement from builder-github

The package gui-agent-linux has been pushed to the r4.0 stable repository for the CentOS centos8 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

@qubesos-bot
Copy link

Automated announcement from builder-github

The component gui-agent-linux (including package pulseaudio-qubes-4.0.34-1.fc32) has been pushed to the r4.0 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

@qubesos-bot qubesos-bot mentioned this issue Feb 13, 2021
Closed
@qubesos-bot
Copy link

Automated announcement from builder-github

The package qubes-gui-agent_4.1.16-1+deb10u1 has been pushed to the r4.1 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

@qubesos-bot
Copy link

Automated announcement from builder-github

The package gui-agent-linux has been pushed to the r4.1 stable repository for the CentOS centos8 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

@qubesos-bot
Copy link

Automated announcement from builder-github

The component gui-agent-linux (including package pulseaudio-qubes-4.1.16-1.fc32) has been pushed to the r4.1 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

@qubesos-bot
Copy link

Automated announcement from builder-github

The package pulseaudio-qubes-4.1.16-1.fc32 has been pushed to the r4.1 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C: gui-virtualization diagnosed Technical diagnosis has been performed (see issue comments). P: critical Priority: critical. Between "major" and "blocker" in severity. r4.0-bullseye-stable r4.0-buster-stable r4.0-centos7-stable r4.0-centos8-stable r4.0-fc31-stable r4.0-fc32-stable r4.0-fc33-stable r4.0-stretch-stable r4.1-bullseye-stable r4.1-buster-stable r4.1-centos8-stable r4.1-dom0-stable r4.1-fc31-stable r4.1-fc32-stable r4.1-fc33-stable T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Projects
None yet
Milestone
Release 4.0 updates
Development

Successfully merging a pull request may close this issue.

Fix globally active clients DemiMarie/qubes-gui-agent-linux