Popup menus don't appear at all if opened close to inter-monitor boundaries in Wayland sessions

[Andy Whitcroft]

I have two (hopefully related) problems with popup-menus for applications on an external monitor. For background I have two displays, the first a builtin LCD panel, the second and HDMI connected LCD monitor. The external monitor is stacked "above" the internal LCD panel, the internal LCD panel is the "primary" display from a where the dash et al are placed.

The first issue occurs with gnome-terminal. When using right-click on an element in the window such as a link, a menu is shown to allow OpenURL et al. This menu will not appear when the link it too close to the bottom of the upper display (the external one); the cursor changes to the arrow menu item selector cursor but not menu is rendered. This occurs regardless of whether the window is maximised and it related to proximity to the boundary of the display. It behaves correctly at the bottom boundary of the lower display. Two screenshots attached showing it working/not-working.

The second issue occurs in firefox. When it is rendered on the upper displays its internal menus are displayed at the top of the lower display rather than on the upper display rooted at the menu item itself. This also does not occur on the lower display. Screenshot attached.

[Daniel van Vugt (vanvugt)]

Might be related to bug 1802331.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

The first issue with Terminal is being tracked upstream in https://gitlab.gnome.org/GNOME/mutter/-/issues/1768

The second issue with Firefox (which the new design does not exhibit but other apps do still) is being tracked upstream in https://gitlab.gnome.org/GNOME/mutter/-/issues/1783

[Launchpad Janitor (janitor)]

This bug was fixed in the package mutter - 42~beta-1ubuntu2

---------------
mutter (42~beta-1ubuntu2) jammy; urgency=medium

  * debian/patches: Skip monitor-size tests that may fail on autopkgtest

 -- Marco Trevisan (Treviño) <email address hidden> Mon, 14 Mar 2022 02:27:21 +0100