After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 764310 - Certain menus display at wrong position in configured multi-monitor setups under Wayland
Certain menus display at wrong position in configured multi-monitor setups un...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-03-29 14:29 UTC by Tiffany Bennett
Modified: 2018-04-14 23:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot of the incorrect behaviour (25.44 KB, image/png)
2016-03-29 14:29 UTC, Tiffany Bennett
Details

Description Tiffany Bennett 2016-03-29 14:29:08 UTC
Created attachment 324941 [details]
Screenshot of the incorrect behaviour

I have two monitors, and they have differing vertical resolutions. The default is to align them along the top axis, but this doesn't match how they line up physically, so I arranged the monitors. On a previous version, this crashed me out to GDM, but on this version, it makes certain menus on all monitors (not just the one whose position I adjusted) be offset by approximately the amount I shifted the one monitor.

OS is Fedora 23. Monitor setup is one 1366x768 monitor and one 1920x1080 monitor.

This only happens under some applications. Particularly, it seems to be happening to any application that is both using GTK3 (doesn't happen in Firefox or Hexchat) and uses old-style menu bars (so it doesn't happen in Nautilus or Shotwell). Applications where it does occur include Gnome Terminal, Emacs, Liferea, and Evolution. It doesn't seem to matter whether the application is running native or under xwayland.
Comment 1 Olivier Fourdan 2016-05-13 12:01:06 UTC
Actually, I don't think this is mutter, but gtk/gdk. 

Looks like it's basing it's placing its menu based on the workarea using the 1st monitor size and position...

This is still broken in 3.20 and current master, and can cause the menu to be placed completely off screen depending on the monitor layout...

=> moving to gtk+
Comment 2 Olivier Fourdan 2016-05-13 13:27:25 UTC
gtkmenu uses the workarea of the monitor where the menu is placed by doing:

 gdk_device_get_position (pointer, ..., &x, &y);
 monitor_num = gdk_screen_get_monitor_at_point (screen, x, y);
 gdk_screen_get_monitor_workarea (screen, monitor_num, &workarea);

On Wayland, there is no global coordinates so gdk_device_get_position() returns relative position to the toplevel, so it will most likely fall in the first monitor. That in itself is wrong, but it won't cause much problem for most as the first monitor is usually placed in (0, 0).

But if the monitor layout is set so the first monitor is shifted down, these values returned by gdk_device_get_position() fall outside of any monitor. 

                +----------------------+
 x              |                      |
                |                      |
+---------------+                      |
|               |                      |
|               |                      |
|               |                      | 
|               |                      | 
+---------------+----------------------+


PS: I reckon X11 impl is wrong as well, not as bad, but still wrong as it uses the workarea which is shifted down and reduced in height by the location of the first monitor, using such a monitor layout so the menu is misplaced as well on X11..
Comment 3 Olivier Fourdan 2016-05-13 16:02:10 UTC
This case should be covered by bug 756579
Comment 4 Matthias Clasen 2018-02-10 05:12:34 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 5 Matthias Clasen 2018-04-14 23:58:55 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new