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 672163 - GtkWindows (comboboxes, menus, etc.) do not show up on primary display
GtkWindows (comboboxes, menus, etc.) do not show up on primary display
Status: RESOLVED OBSOLETE
Product: mutter
Classification: Core
Component: general
3.3.x
Other Linux
: High critical
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2012-03-15 16:36 UTC by Debarshi Ray
Modified: 2021-07-05 13:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Multi-head setup which works (22.76 KB, image/png)
2012-03-20 13:17 UTC, Debarshi Ray
  Details
Multi-head setup which is broken (22.79 KB, image/png)
2012-03-20 13:17 UTC, Debarshi Ray
  Details
x11: Deal better with L-shaped monitor arrangements (1.56 KB, patch)
2012-03-22 21:47 UTC, Matthias Clasen
none Details | Review
x11: Deal better with L-shaped monitor arrangements (1.67 KB, patch)
2012-03-23 12:13 UTC, Matthias Clasen
committed Details | Review
workspace: Make sure the work area overlaps with the primary monitor (2.67 KB, patch)
2012-03-23 12:40 UTC, Rui Matos
rejected Details | Review

Description Debarshi Ray 2012-03-15 16:36:17 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
Comment 1 Matthias Clasen 2012-03-19 03:25:38 UTC
Firefox is using gtk2, so no wonder this problem doesn't occur there.
Comment 2 Matthias Clasen 2012-03-19 03:29:31 UTC
Is this a setup with 2 screens, or just multiple monitors in a single screen ?
Comment 3 Debarshi Ray 2012-03-19 12:26:39 UTC
(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.
Comment 4 Matthias Clasen 2012-03-20 01:48:36 UTC
I need to remember to test this in the office, with an external monitor
Comment 5 Matthias Clasen 2012-03-20 12:26:48 UTC
I can't reproduce. Debarshi, do you have any hints as to how this happens - is this only in a specific multihead setup (overlaps) ?
Comment 6 Debarshi Ray 2012-03-20 12:59:21 UTC
(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.
Comment 7 Debarshi Ray 2012-03-20 13:17:40 UTC
Created attachment 210177 [details]
Multi-head setup which works
Comment 8 Debarshi Ray 2012-03-20 13:17:59 UTC
Created attachment 210178 [details]
Multi-head setup which is broken
Comment 9 Debarshi Ray 2012-03-20 13:19:44 UTC
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.
Comment 10 Matthias Clasen 2012-03-20 21:03:21 UTC
Very peculiar. Thanks for the detailed instructions, I'll try again tomorrow morning
Comment 11 Matthias Clasen 2012-03-21 13:32:47 UTC
Unfortunately, it still doesn't reproduce here.
Comment 12 Matthias Clasen 2012-03-22 21:19:04 UTC
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.
Comment 13 Matthias Clasen 2012-03-22 21:47:31 UTC
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.
Comment 14 Matthias Clasen 2012-03-22 21:48:07 UTC
Debarshi, can you test this patch ?
I'll test it tomorrow when I get back to the office.
Comment 15 Rui Matos 2012-03-23 10:38:20 UTC
(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.
Comment 16 Matthias Clasen 2012-03-23 11:38:28 UTC
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
Comment 17 Matthias Clasen 2012-03-23 12:13:01 UTC
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.
Comment 18 Rui Matos 2012-03-23 12:40:49 UTC
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.
Comment 19 Matthias Clasen 2012-03-23 13:40:46 UTC
Moving this to mutter for the remaining patch.
For reference:

https://mail.gnome.org/archives/wm-spec-list/2009-November/msg00005.html
Comment 20 Owen Taylor 2012-03-23 15:15:27 UTC
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
Comment 21 Kjartan Maraas 2017-04-06 21:36:22 UTC
Removing the GNOME 3.4 target.
Comment 23 GNOME Infrastructure Team 2021-07-05 13:45:32 UTC
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.