override_redirect protection breaks context menus on ultrawide

[n0madK]

Qubes OS version

Qubes 4.1

Brief summary

When I connect an ultrawide monitor to a laptop, then open a context menu in an application on the far right side of the screen, the overridde_redirect protection triggers and the context menu does not open.

To Reproduce

Steps to reproduce the behavior:

1. Boot laptop
2. Start Thunderbird
3. Connect ultrawide monitor
4. Q->System Tools->Display, disable laptop screen
5. Drag Thunderbird to the right-side
6. Right-click on an email

Expected behavior

Context menu opens.

Actual behavior

Context menu flickers and closes. The override_redirect protection popup shows.

Solutions you've tried

Restarting the VM after the screen settings have been changed allows the context menu to behave as expected

Additional context

When opening the context menu, a window opens that extends from the left edge of the screen to the place where the context menu should open, then immediately closes. I wonder if:

1. the application (Thunderbird) is first opening a window the full width of the current screen before resizing
2. the xside.c retains the original screen geometry at VM boot time (ie changing the screen size does not propagated to running VMs) - https://github.com/QubesOS/qubes-gui-daemon/pull/41/files#diff-7897f6116dd3815ad17499205f816d770805aca6ce63e96ff55be4fe2d95a3d6R1147

I'm not sure how to debug this, but I also don't see how else this bug would trigger.

Related, non-duplicate issues

https://github.com/QubesOS/qubes-gui-daemon/pull/41 https://github.com/QubesOS/qubes-issues/issues/4705

[SaswatPadhi]

After a dom0 update this bug appears on my system too. It's super annoying! Basic apps that used to work fine (like Firefox) now crash quite often.

• First a popup shows up regarding override_redirect
• At some point the window closes and GUI for the AppVM crashes
• Only solution is to restart the AppVM and hope that I don't hit the bug again

Here's what I see in the guid.<appvm>.log:

invalid PMaxSize for 0x54001d2 (32766/32766)
invalid PMaxSize for 0x54001e3 (32766/32766)
invalid PMaxSize for 0x54001e6 (32766/32766)
This VM has attempted to create a very large window in a manner that would have prevented you from closing it and regaining the control of Qubes OS's graphical user interface.

As a protection measure, the "override_redirect" flag of the window in question has been unset. If this creates unexpected issues in the handling of this VM's windows, please set "override_redirect_protection" to "false" for this VM in /etc/qubes/guid.conf to disable this protection measure and restart the VM.

This message will only appear once per VM per session. Please click on this notification to close it.
ErrorHandler: BadAccess (attempt to access private resource denied)
                 Major opcode: 130 (MIT-SHM)
                 Minor opcode: 1 (X_ShmAttach)
                 ResourceID:   0x54001e7
                 Failed serial number:  2170
                 Current serial number: 2171
XShmAttach failed for window 0x54001e6(remote 0x800048)
ErrorHandler: BadAccess (attempt to access private resource denied)
                 Major opcode: 130 (MIT-SHM)
                 Minor opcode: 1 (X_ShmAttach)
                 ResourceID:   0x54001e0
                 Failed serial number:  2191
                 Current serial number: 2192
XShmAttach failed for window 0x54001e6(remote 0x800048)

[SaswatPadhi]

Also note that, the warning states:

please set "override_redirect_protection" to "false" for this VM in /etc/qubes/guid.conf to disable this protection measure

But at the top of /etc/qubes/guid.conf we see:

# EDITING THIS FILE WILL NOT HAVE ANY EFFECT! It is not read by GUI daemon
# anymore, and is left here for reference only. To configure the GUI daemon,
# use qvm-features (see 'man qvm-features' for details).

Can we:

1. update warning so it states the qvm-features commandline to be used?
2. provide a UI to flip this Qube Manager? at least globally in dom0, because we do so for allow_fullscreen etc.

[andrewdavidwong]

2. provide a UI to flip this Qube Manager? at least globally in dom0, because we do so for allow_fullscreen etc.

This should be filed as a separate issue, as it would be a separate enhancement.

[na--]

This bug regularly occurs for me and messes up the NetworkManager's sys-net system tray icon, despite the fact that I should have disabled the override_redirect protection (I'm on 4.1) through qvm-features :confused:

$ qvm-features sys-net gui-override-redirect-protection
false

[SaswatPadhi]

Same for me. This issue is making it impossible for me to use most apps, like Firefox, which show context menus / popups.

Could someone please state the exact steps to disable this?

[marmarek]

$ qvm-features sys-net gui-override-redirect-protection false

String "false" actually is not a boolean negative value... An empty string is (see man qvm-features). So, it should be:

qvm-features sys-net gui-override-redirect-protection ""

But also, it should not trigger on normal usage, and I never got it for NetworkManager, Firefox or any other similar common applications. Can anyone who is affected set debug property on an affected qube to "1" (or true or similar) and then send a guid log when the issue happens?

[SaswatPadhi]

Yes sure, I can try to post a debug log in a bit.

Thanks a lot for the instructions as well, @marmarek!

[n0madK]

I can reproduce this 100% of the time with the steps in my first post. guid.email.log

After disabling gui-override-redirect-protection and triggering the issue, the top right menu completely breaks in Thunderbird:

1. Start email vm
2. Plug in ultrawide monitor
3. Drag Thunderbird off the laptop screen to the right
4. Open the menu (nothing happens)
5. Drag Thunderbird back onto the laptop screen
6. Open the menu (nothing happens)

I have to close and re-open the Thunderbird to recover. guid.email.log

[marmarek]

Thanks, that's exactly the log I needed!

handle_configure_from_vm, local 0x5e00232 remote 0x140013e, 338/605, was 200/200, ovr=1, xy 2693/146, was 0/0
force_on_screen(from handle_configure_from_vm) returns 1 (reason 3): window 0x5e00232, xy 2693 146, wh 338 605, work area 1920 1080 borderwidth 0
XMoveResizeWindow local 0x5e00232 remote 0x140013e, xy 2693 146 (vm_window is 2693 146) wh -773 605
MSG_WINDOW_DUMP for 0x5e00232(0x140013e): 338x605, type = 0
process_xevent_configure(synth 0) local 0x5e00232 remote 0x140013e, 64763/605, was -773/605, xy 2693/146 was 2693/146

Negative size! It wrapped around into absurdly large window. I guess something went wrong in https://github.com/QubesOS/qubes-gui-daemon/pull/56

[marmarek]

work area 1920 1080

Is this accurate for your (combined) screen size? if you have external monitor connected, then likely not... Can you check xprop -root _NET_WORKAREA in dom0?

[n0madK]

Laptop only

$ xprop -root _NET_WORKAREA
_NET_WORKAREA(CARDINAL) = 0, 39, 1920, 1041, 0, 39, 1920, 1041, 0, 39, 1920, 1041

Monitor only

$ xprop -root _NET_WORKAREA
_NET_WORKAREA(CARDINAL) = 0, 39, 5120, 1401, 0, 39, 5120, 1401, 0, 39, 5120, 1401

Laptop+monitor mirrored

$ xprop -root _NET_WORKAREA
_NET_WORKAREA(CARDINAL) = 0, 39, 5120, 1401, 0, 39, 5120, 1401, 0, 39, 5120, 1401

[qubesos-bot]

Automated announcement from builder-github

The package gui-daemon has been pushed to the r4.1 testing repository for the CentOS centos-stream8 template. To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.1-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-audio-daemon-4.1.14-1.fc32 has been pushed to the r4.1 testing repository for dom0. To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-gui-daemon_4.1.14-1 has been pushed to the r4.1 testing repository for the Debian template. To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing buster-testing (or appropriate equivalent for your template version), then use the standard update command:

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

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component gui-daemon (including package qubes-audio-daemon-4.1.14-1.fc32) has been pushed to the r4.1 testing repository for the Fedora template. To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.1-current-testing

Changes included in this update

[SaswatPadhi]

Thanks for fixing this @marmarek @DemiMarie

Although the dom0 warning about override_redirect protection is gone, the context menus still are broken :( The context menus often appear at another part of the screen (or on a different monitor). May be there is some bug with the offset calculations?

I will try to post a screenshot.

[marmarek]

Can you post gui-daemon log from the affected qube? See /var/log/qubes/guid.<name>.log. You may need to set debug property of that qube to "true" first and restart it (qvm-prefs <name> debug true).

[SaswatPadhi]

Please find a screenshot and the gui-daemon log below.

I have two displays (external 1920x1200 + laptop 1920x1080) that are stacked vertically. I opened Firefox in a test VM and right clicked inside it with the Firefox window being in the laptop monitor. The context menu appears in the external monitor as you can see in the screenshot.

guid.test.log

[marmarek]

I have two displays (external 1920x1200 + laptop 1920x1080) that are stacked vertically.

work area 0 1229 1920 1051

This looks weird - it declares only the lower display as usable (the format is "x y width height" of a usable space). Can you show xprop -root _NET_WORKAREA? I see you have the panel between the screens - likely that makes Xfce set it this way. Does it change if you move focus (or just mouse?) to the top display?

force_on_screen(from handle_configure_from_vm) returns 1 (reason 20): window 0x70001e5, xy 1574 1473, wh 210 220, work area 0 1229 1920 1051 borderwidth 0

"reason 20" is about bottom border. And indeed the code confuses bottom border (max y) with max height...

[SaswatPadhi]

Thanks @marmarek! Indeed stacking the displays vertically is buggy -- stacking horizontally works totally fine.

This looks weird - it declares only the lower display as usable (the format is "x y width height" of a usable space). Can you show xprop -root _NET_WORKAREA?

In dom0 I get:

_NET_WORKAREA(CARDINAL) = 0, 1229, 1920, 1051, 0, 1229, 1920, 1051, 0, 1229, 1920, 1051, 0, 1229, 1920, 1051, 0, 1229, 1920, 1051, 0, 1229, 1920, 1051

When stacked horizontally, I get:

_NET_WORKAREA(CARDINAL) = 0, 29, 3840, 1171, 0, 29, 3840, 1171, 0, 29, 3840, 1171, 0, 29, 3840, 1171, 0, 29, 3840, 1171, 0, 29, 3840, 1171

I see you have the panel between the screens - likely that makes Xfce set it this way. Does it change if you move focus (or just mouse?) to the top display?

No, the context menu stays where it is in the screenshot even when I change focus / move mouse.

I also tried moving the Firefox window to the other display (the one above) and the context menus still appear at incorrect locations.

[SaswatPadhi]

The 1229 looks very weird in the first output. It's basically 1200 (top display height) + 29 (panel height).

As a guess, I tried to disable "Don't reserve space on borders" in the preferences for the panel. And that fixed the issue with _NET_WORKAREA calculation and the context menus appear as expected. But my window title bars are now hidden below the panel ...

Thanks again for all the help, @marmarek! This probably is an Xfce issue, not a Qubes issue?

[marmarek]

No, it is a qubes issue. This option should work exactly the way it's described - avoid windows to cover the panel - but the context menu didn't tried to cover the panel and was moved anyway.

[qubesos-bot]

Automated announcement from builder-github

The package gui-daemon has been pushed to the r4.1 testing repository for the CentOS centos-stream8 template. To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.1-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-audio-daemon-4.1.15-1.fc32 has been pushed to the r4.1 testing repository for dom0. To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-gui-daemon_4.1.15-1 has been pushed to the r4.1 testing repository for the Debian template. To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing buster-testing (or appropriate equivalent for your template version), then use the standard update command:

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

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component gui-daemon (including package qubes-audio-daemon-4.1.15-1.fc32) has been pushed to the r4.1 testing repository for the Fedora template. To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.1-current-testing

Changes included in this update

[SaswatPadhi]

Hello,

I have upgraded the GUI and Audio daemons, but this issue is not fully fixed yet.

[user@dom0 ~]$ sudo dnf list --installed | egrep '(gui|audio)-daemon'
qubes-audio-daemon.x86_64                    4.1.15-1.fc32                    @qubes-dom0-cached
qubes-gui-daemon.x86_64                      4.1.15-1.fc32                    @qubes-dom0-cached

What works correctly now: Context menus for Firefox open in the monitor below (same monitor as the panel) appear correctly (in the same monitor).

What doesn't work correctly: Context menus for Firefox open in the monitor above (the one above the panel) appear in the other monitor.

The _NET_WORKAREA that I see in dom0 is the same as before (see: https://github.com/QubesOS/qubes-issues/issues/6518#issuecomment-899638264). Please let me know if I could provide any other logs that might help you fix this issue.

Thanks.

[SaswatPadhi]

Here is a screenshot:

When I right click within Firefox window in the top monitor, the context menu appears on the bottom monitor. I also noticed that the context menu has the correct X coordinate (horizontal offset), but the Y coordinate (vertical offset) seems fixed to top of the second monitor (so 1229, I think).

[marmarek]

Ok, so I'm afraid(?) this is exactly what Xfce requested to do:

_NET_WORKAREA(CARDINAL) = 0, 1229, 1920, 1051, ...

This means Xfce requested to not use area outside of 1920x1051 rectangle at (0, 1229). I'm not sure how a panel between monitors should be represented, but the way it currently is, should result in windows appearing only on the bottom screen...

[SaswatPadhi]

Thanks @marmarek. I agree that this looks like an Xfce issue at this point. I could set this panel to auto hide and that works well for now.

One remaining question I have is, how does normal window placement work? As in, why are we able to place Firefox in the top monitor (either by dragging it there, or the default placement when mouse is in the monitor), but we can't place context menus there?

[SaswatPadhi]

Also, dom0 context menus work correctly in both monitors, it's just AppVM context menus that have this issue.

[marmarek]

We try to be a bit stricter how VM can place its windows, to prevent it obscuring critical UI elements. With dom0 windows, it's directly responsibility of the window manager only, and apparently it knows more accurate definition of allowed areas. The context menus are outside of window manager control completely, and that's why we need to enforce placement rules on our own.

[DemiMarie]

What does xprop -root show? Is there another property that provides more information? _NET_WORKAREA doesn’t provide enough information for the GUI daemon to properly handle this situation.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-gui-daemon_4.1.15-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]

Automated announcement from builder-github

The component gui-daemon (including package qubes-audio-daemon-4.1.15-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

[qubesos-bot]

Automated announcement from builder-github

The component gui-daemon (including package qubes-audio-daemon-4.1.15-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 dnf update

Changes included in this update