xdg-popups appear at incorrect position

[yannick]

#1142 seems to still exist?!

steps to reproduce:
open an app, e.g. pavucontrol or terminator and get a right click menu. see screenshot.

➜ ~ swaymsg -t get_version
sway version 1.0-beta.1-195-gc36665bc (Nov 15 2018, branch 'master')
➜ ~ pacman -Q wlroots
wlroots-git 0.1.r79.g040d62de-1

sway-wrong-menu.log

[philipflohr]

With my setup this only happens for xwayland windows, right-click works fine for native wayland applications

[yannick]

@philipflohr which sway version? i think it worked for me in an older version.
as you can see in the title bar its not an xwayland window. and funnily enough in xwayland it works for me correctly

[emersion]

Can you send a WAYLAND_DEBUG=1 debug log of pavucontrol?

[yannick]

@emersion
https://gist.github.com/8c7fde478fc842bfc6e948676c8546eb

[yannick]

it also happens in wayland apps (e.g. firefox)

[emersion]

Well, pavucontrol is Wayland-native.

[yannick]

its related to the position settings in sway config.
removing it "fixes" the issue

[emersion]

Can you run swaymsg -t get_outputs to see exactly your configuration?

[RedSoxFan]

I haven't been able to figure out why yet, but for some GTK applications, if the absolute y location of the output is a higher value than the surface local y location of the last wl_pointer motion event before the popup is created, the xdg-positioner's set_anchor_rect's y value is the y location of the output.

Also, the issue occurs in rootston as well so this is not sway specific.

Example snippets from WAYLAND_DEBUG=1 pavucontrol when the sink selection button is clicked for a sink input.

1. Output Y: 400 -- Motion Y: 186.460938 -- Anchor Y: 400

[email protected](0, 400, 344, 193, 0, "Unknown", "0x38ED", 0)
-> [email protected](257345051, 824.769531, 186.460938)
[email protected]_anchor_rect(828, 400, 1, 1)

2. Output Y: 100 -- Motion Y: 179.523438 -- Anchor Y: 180

[email protected](0, 100, 344, 193, 0, "Unknown", "0x38ED", 0)
-> [email protected](258462167, 794.757812, 179.523438)
[email protected]_anchor_rect(798, 180, 1, 1)

[RedSoxFan]

More information:

• If the surface local x position is less than the left-most output's x position, the anchor rect's x value will be the left-most output's x position.
• If the surface local y position is less than the top-most output's y position, the anchor rect's y value will be the top-most output's y position.

[RedSoxFan]

This is caused by applications using the function gtk_menu_popup() which was deprecated in GTK 3.22.

Please submit patches or report to effected applications to have them update to use one of the newer functions.

https://bugzilla.gnome.org/show_bug.cgi?id=772096#c10
https://developer.gnome.org/gtk3/stable/GtkMenu.html#gtk-menu-popup

[edrex]

I'm seeing the same behavior as with FF and pavucontrol with menus in Calibre, a pyqt5 application. Since this is happening for both GTK and QT apps doesn't this indicate a bug in wlroots?

I played around with positioning a bit and the results match @RedSoxFan's description of the way the coordinates are transformed.

[RedSoxFan]

I have not looked into the issue with QT since I was not aware of any QT application that showed the behavior. However, the GTK issue is definitely due to the deprecated function in my previous comment. My guess is QT may have a similar function or it is an issue with Calibre itself. I can take a look into it in a few hours

[edrex]

Same issue with popups in Krita, another pyqt app, which runs xwayland because of tablet stuff (checked via xprop, which interestingly acts like an xwayland client in that it is blurry on hidpi, but seems to be running native. Calibre was running native wayland.

So with QT at least, the problem is present in both modes.

[RedSoxFan]

Are you aware of any QT application that isn't using the pyqt bindings that has the issue? Nevermind, this is not pyqt specific. See my next comment

[RedSoxFan]

For QT apps see: https://community.kde.org/Guidelines_and_HOWTOs/Wayland_Porting_Notes

Summary in case the link breaks in the future: QMenu needs to either have a parent or use mapToGlobal with an event position in order for the menu's to be positioned correctly in Wayland. QCursor::pos should not be used under Wayland.

Similar to the message for GTK apps above, please submit patches or report to effected applications to have them update their logic for Wayland.

[J0nnyMak0]

I went ahead and reported to mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=1528021