GNOME Bugzilla – Bug 672163
GtkWindows (comboboxes, menus, etc.) do not show up on primary display
Last modified: 2021-07-05 13:45:32 UTC
On a dual-head setup, if I right-click URLs, or click menus or comboboxes on the primary display (a laptop) the window does not show up. However they do show up on the secondary display (a monitor). If I restart with a single-head setup the problem goes away. Interestingly, even on dual-head setups the problem does not show up in some applications like Firefox. I am using a F16 system with these unstable packages from F17: gtk3-3.3.18-1.fc16.x86_64 glib2-2.31.20-1.fc16.x86_64 adwaita-gtk2-theme-3.3.91-1.fc16.x86_64 adwaita-cursor-theme-3.3.91-1.fc16.noarch adwaita-gtk3-theme-3.3.91-1.fc16.x86_64 gnome-settings-daemon-3.3.91-1.fc16.x86_64 gsettings-desktop-schemas-3.3.90-1.fc16.x86_64
Firefox is using gtk2, so no wonder this problem doesn't occur there.
Is this a setup with 2 screens, or just multiple monitors in a single screen ?
(In reply to comment #2) > Is this a setup with 2 screens, or just multiple monitors in a single screen ? Multiple monitors in a single screen.
I need to remember to test this in the office, with an external monitor
I can't reproduce. Debarshi, do you have any hints as to how this happens - is this only in a specific multihead setup (overlaps) ?
(In reply to comment #5) > I can't reproduce. Debarshi, do you have any hints as to how this happens - is > this only in a specific multihead setup (overlaps) ? Well, it is a Thinkpad x220 and a NEC monitor. The laptop is the primary and the monitor secondary. The only unusual thing that I can think of is that the monitor is rotated 90 degrees anticlockwise.
Created attachment 210177 [details] Multi-head setup which works
Created attachment 210178 [details] Multi-head setup which is broken
As you can make out from the pictures, if I place the primary laptop towards the bottom of the anticlockwise rotated secondary monitor, then you can notice this bug. However, if you drag the laptop a bit higher, or unrotate the secondary monitor, then things work.
Very peculiar. Thanks for the detailed instructions, I'll try again tomorrow morning
Unfortunately, it still doesn't reproduce here.
I've now reproduced this, and it appears that in the case of an l-shaped screen like this, the menus that would normally placed in the upper part of the L are forced below the upper edge of the primary monitor. This is almost certainly an issue with the workarea-constainment work. Either the shell puts up full-width struts that extend across the secondary monitor, or we are interpreting them wrong.
Created attachment 210384 [details] [review] x11: Deal better with L-shaped monitor arrangements The code for calculating the per-monitor workarea was ignoring the fact that the EWMH workarea property can only handle rectangular workareas, and thus can't really do justice to general monitor arrangements. As a workaround, we ignore it for anything but the primary monitor.
Debarshi, can you test this patch ? I'll test it tomorrow when I get back to the office.
(In reply to comment #13) > Created an attachment (id=210384) [details] [review] > x11: Deal better with L-shaped monitor arrangements > > The code for calculating the per-monitor workarea was ignoring > the fact that the EWMH workarea property can only handle rectangular > workareas, and thus can't really do justice to general monitor > arrangements. As a workaround, we ignore it for anything but > the primary monitor. Sadly, this patch doesn't fix this particular monitor configuration under mutter. The problem is the way in which mutter computes the work area. Mutter tries to find the biggest area rectangle among the minimal set of spanning rectangles, in this case, this minimal set is composed of rectangles A and B: | Aw | + -------+- | | | | | | | | +-------+ | Ah -+-------+........| | . | Bh| . | | . | -+----------------+- | Bw | Since (Aw x Ah) > (Bw x Bh) mutter sets the workarea as the A rectangle which doesn't cover the primary monitor at all. Now, with this patch in gtk+ and changing mutter to choose a rectangle that always includes the primary monitor as the workarea I think the bug can be fixed for now. _NET_WORKAREA's definition really needs some updating for the multi-monitor case though.
We can try harder by ignoring the workarea for the primary monitor as well, if it doesn't even overlap... But yeah, this is beginning to look ridiculous
Created attachment 210408 [details] [review] x11: Deal better with L-shaped monitor arrangements The code for calculating the per-monitor workarea was ignoring the fact that the EWMH workarea property can only handle rectangular workareas, and thus can't really do justice to general monitor arrangements. As a workaround, we ignore it for anything but the primary monitor. And we ignore it for the primary monitor as well if it does not even cover it.
Created attachment 210412 [details] [review] workspace: Make sure the work area overlaps with the primary monitor -- (In reply to comment #16) > We can try harder by ignoring the workarea for the primary monitor as well, if > it doesn't even overlap... This mutter patch should fix it together with your previous patch. Ignoring the work area altogether wouldn't fix bug 633620 for these multi-monitor layouts.
Moving this to mutter for the remaining patch. For reference: https://mail.gnome.org/archives/wm-spec-list/2009-November/msg00005.html
Review of attachment 210412 [details] [review]: It certainly seems like the region list generated by meta_rectangle_get_minimal_spanning_set_for_region() could include rectangles that just barely overlap with the primary monitor - I think that would be the case if the panel strut, for example, extended across only 90% of the width of the primary monitor - then rectangle A would intersect the primary monitor, but just a little bit. So, if anything, I'd expect this patch to look something like: - Pass an extra rectangle to meta_rectangle_clip_to_region() which is the rectangle to used when computing the overlap (probably optional and defaulting to the passed in rectangle to clip) - Pass in the primary monitor area for that But I'm not really sure that that is justified - the current work area we set is more or less the largest single rectangle that fits around the struts and this seems like about as valid an approach as anything else. Certainly in terms of the situation in this bug, one is as broken as the other - the only thing we can use to constrain menus to not cross struts would be a more complete knowledge of the exact monitor area - struts. The idea that the workarea is validish for constraining menus on the primary monitor but not on other monitors doesn't make a ton of sense to me. Let's just try to fix this properly for the next cycle A) If we don't want menus to cross struts, let's have Mutter set some property that is what GTK+ needs B) If we do want menus to cross struts, then we have a pretty good idea of how to rework Mutter to let popups cross the panel, someone just needs to sit down for a week or two and implement it
Removing the GNOME 3.4 target.
Related merge requests - https://gitlab.gnome.org/GNOME/mutter/merge_requests/370 and https://gitlab.gnome.org/GNOME/gtk/merge_requests/478.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.