Closed Bug 1606010 Opened 4 years ago Closed 3 years ago

[Wayland] Right-click menus near screen edge and some tooltips are displayed on wrong screen in dual monitor setup

Categories

(Core :: Widget: Gtk, defect, P2)

Product:
Core
Component:
Widget: Gtk
Platform:
Unspecified
Linux
Type:
defect

Tracking

()

Status:
RESOLVED MOVED
Milestone:
90 Branch
Tracking Flags:
Tracking Status
firefox-esr68 --- wontfix
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox90 --- fixed

People

(Reporter: viktor_jaegerskuepper, Assigned: jhorak)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Bug 1606010 Don't prefer scale of popup menu instead of shift; r=stransky
48 bytes, text/x-phabricator-request
Details | Review

My setup consists of two monitors, both with standard scaling (no HiDPI), the primary screen has no offset ("on the left") and the second screen has a horizontal offset 1280 (the horizontal resolution of the primary screen).

When Firefox is displayed maximized on the primary screen, some tooltips (e.g. the one for the hamburger menu) are often displayed on the second screen.

With mozregression I found that this is a regression introduced by bug 1546374.

Blocks: wayland
status-firefox71: --- → affected
status-firefox72: --- → affected
Keywords: regression
Regressed by: 1546374
Has Regression Range: --- → yes

Too late for a fix in 71/72 but we could still take a patch for 73.

status-firefox71: affected → wontfix
status-firefox72: affected → wontfix

Jan, can you look at it please?
Thanks.

Assignee: nobody → jhorak
Priority: -- → P2

Martin, Jan, could we have an update on this bug status please? Thanks

Flags: needinfo?(stransky)

(In reply to Pascal Chevrel:pascalc from comment #3)

Martin, Jan, could we have an update on this bug status please? Thanks

Pascal,

this affects Fedora 31 wayland builds only right now. Mozilla builds, Ubuntu and other distros are not affected as well as fedora x11 builds, so there's no need to worry much about this one.

Flags: needinfo?(stransky)

Just want to mention that several popular configurations require switch to Wayland to be usable. Such as devices with input via touchscreen, like Dell 7285, 9250 and HP Elite x2 1013 G3 (on-screen keyboard and touch gestures is not fully functional in Gnome Shell Xorg session) devices that need fractional scaling, like many small laptops with FullHD display (for example Lenovo Miix 320-10ICR and HP EliteBook Folio G1; in Gnome Shell Xorg session there is tearing with enabled fractional scaling due to unimplemented TearFree mode in modesetting DDX) and devices that connected to HiDPI and non-HiDPI displays (like laptop with HiDPI display and external regular display attached via docking station, or nettop connected to HiDPI display and regular display).

In all this cases switch to Wayland session is easiest and most reliable solution. Running Firefox via XWayland does not help in such cases - on-sreen keyboard doesn't pop up on touching input field, Firefox window is blurry when fractional scaling is enabled in Wayland session, Firefox window doesn't adjust on moving between HiDPI and non-DPI display (although last one is broken since Firefox 72, even with enabled Wayland support, at least judging by my short test on Dell 5855 with Dell WD15 attached to Dell UP3017).

So, shorty my point is - while Gnome Shell Wayland session is not default in Ubuntu, users with modern hardware is forced to switch from Xorg to Wayland, so such users getting this bug.

Victor, please retest with latest nightly. Bug 1605795 could also address this one.

Flags: needinfo?(viktor_jaegerskuepper)

Unfortunately this bug is not fixed for me.

Flags: needinfo?(viktor_jaegerskuepper)

I noticed that there is a more important problem than what I originally described: If I right-click on a link that is near the right screen edge of my primary/left screen, the menu is not displayed on the primary/left screen, but on the secondary/right screen.

Steps to reproduce:

  1. Go to google.com
  2. Right-click on "Sign in" (upper right edge) or "Settings" (lower right edge)
    -> menu is displayed on secondary screen

I used mozregression and found that this is also caused by bug 1546374, so I am not filing another bug because both problems seem to be related from my point of view.

Side note: Bug 1562576 is another regression of bug 1546374 and one part of it looks related to this one.

See Also: → 1562576
Summary: [Wayland] Some tooltips are displayed on wrong screen in dual monitor setup → [Wayland] Right-click menus near screen edge and some tooltips are displayed on wrong screen in dual monitor setup

I am also having this issue on Ubuntu 20.04 on Wayland with 2 monitors.

See screenshot of lastpass partially rendering off-screen which makes some buttons impossible to press - https://imgur.com/os9G4Pf

See Also: → 1662779

I can confirm this issue on fedora 33 and firefox nightly build from 12th april 2021. Also the display of the context menus can be broken like in this image: https://ibb.co/Stsk2L1

Blocks: wayland-popup
No longer blocks: wayland

I'm afraid that this is not actually bug. The popup is placed by the compositor. Firefox only gives a hint where to place it. It's up to compositor where it actually move it. I've tried the gedit and it basically act the same. Could you please check the behavior of gedit?
https://ibb.co/fFg6nHW
https://ibb.co/RbWSQwq

Flags: needinfo?(viktor_jaegerskuepper)

It's almost the same as gedit.

In Firefox there are two additional bugs or artifacts.

  1. The menu is sized too small.

The menu appears to be sized as if it's shown on both monitors. So if it's supposed to be 100 pixels wide, and 30 pixels appear on the one monitor and 70 on the other, only the menu on the second monitor is rendered, and it's 70 pixels wide chopping off some of the menu. If the mouse cursor is very far over and only 5 pixels are chopped, this isn't noticeable.

Half menu https://ibb.co/0J0D0bD

  1. Submenus are not available.

Submenus appear to not render, or not be available. Moving to the incomplete menu doesn't render the submenu if the submenu should appear on the second screen. In gedit the submenu is rendered.

Submenus do render if the entire context menu is on one screen, and no pixels are cut off.

This is for Firefox 88.

(In reply to Jan Horak [:jhorak] from comment #12)

I'm afraid that this is not actually bug. The popup is placed by the compositor. Firefox only gives a hint where to place it. It's up to compositor where it actually move it. I've tried the gedit and it basically act the same. Could you please check the behavior of gedit?
https://ibb.co/fFg6nHW
https://ibb.co/RbWSQwq

I can confirm, that gedit does also place the context menu wrong in this case, but the over problems outlined in this issue only happen with firefox.

Thanks for confirming the problems Berend De Schouwe. That is exactly what happens on my end. Sometimes submenus do not get rendered, when there is not enough room on the monitor to render them side by side.

(In reply to Jan Horak [:jhorak] from comment #12)

I'm afraid that this is not actually bug. The popup is placed by the compositor. Firefox only gives a hint where to place it. It's up to compositor where it actually move it. I've tried the gedit and it basically act the same. Could you please check the behavior of gedit?

I also see this with gedit. Do I understand you correctly that this is a bug in mutter?

Flags: needinfo?(viktor_jaegerskuepper) → needinfo?(jhorak)

(In reply to Berend De Schouwer from comment #13)

It's almost the same as gedit.

In Firefox there are two additional bugs or artifacts.

  1. The menu is sized too small.

The menu appears to be sized as if it's shown on both monitors. So if it's supposed to be 100 pixels wide, and 30 pixels appear on the one monitor and 70 on the other, only the menu on the second monitor is rendered, and it's 70 pixels wide chopping off some of the menu. If the mouse cursor is very far over and only 5 pixels are chopped, this isn't noticeable.

Half menu https://ibb.co/0J0D0bD

I used mozregression and found the following regression window for this (only Nightly builds still available because this is more than one year ago):
Last good revision: 263963426b561b2aa687aeeaeddc4fd93fff9e57 (2020-04-21)
First bad revision: 17aa41e3cb7cdff3b94e26e351e29cc8b9bab18a (2020-04-22)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=263963426b561b2aa687aeeaeddc4fd93fff9e57&tochange=17aa41e3cb7cdff3b94e26e351e29cc8b9bab18a

My guess is that this is caused by bug 1623974. Jan, can you confirm this? Do you think this is a bug in Firefox or mutter?

  1. Submenus are not available.

Submenus appear to not render, or not be available. Moving to the incomplete menu doesn't render the submenu if the submenu should appear on the second screen. In gedit the submenu is rendered.

Submenus do render if the entire context menu is on one screen, and no pixels are cut off.

This is for Firefox 88.

I don't quite understand what you see here. In my setup the submenu is displayed correctly if the cropped menu is displayed on the second screen. However I noticed that the submenu is not displayed sometimes if the context/popup menu is displayed on the first screen. This is what Klaus observes, and I think this is a special case of what Jan reported (for gedit) here:
https://gitlab.gnome.org/GNOME/mutter/-/issues/1768

(In reply to Viktor Jägersküpper from comment #16)

(In reply to Berend De Schouwer from comment #13)

  1. Submenus are not available.

Submenus appear to not render, or not be available. Moving to the incomplete menu doesn't render the submenu if the submenu should appear on the second screen. In gedit the submenu is rendered.

Submenus do render if the entire context menu is on one screen, and no pixels are cut off.

This is for Firefox 88.

I don't quite understand what you see here. In my setup the submenu is displayed correctly if the cropped menu is displayed on the second screen. However I noticed that the submenu is not displayed sometimes if the context/popup menu is displayed on the first screen. This is what Klaus observes, and I think this is a special case of what Jan reported (for gedit) here:
https://gitlab.gnome.org/GNOME/mutter/-/issues/1768

I'll clarify as much as I can.

  1. right click
  2. move mouse over context menu
  3. move mouse to line "send link to device" (seems to be the only submenu available by default) It might only exist if you have more than one device with Firefox running / logged in.
  4. expect submenu with "send to some other firefox"
  5. submenu isn't rendered

There are two conditions where I can't find the submenu, and it's repeatable for me every time. It's only an issue with multiple displays.

  1. The context menu is cropped. If it's cropped enough to remove the '>' icon, the submenu doesn't appear.
  2. The context menu is very close to the screen edge, but rendered on the main display. The submenu should appear either left or on the second display, but it doesn't.

If the context menu is far enough of the screen edge, the submenu is rendered to the left of the context menu. If it's even further left, the submenu is displayed to the right, in it's entirety on the main display.

(In reply to Berend De Schouwer from comment #17)

  1. right click
  2. move mouse over context menu
  3. move mouse to line "send link to device" (seems to be the only submenu available by default) It might only exist if you have more than one device with Firefox running / logged in.

I don't see this (probably because I am not logged in with a Firefox account), but if you use Nightly, there is also a context menu entry "Open Link in New Container Tab" with a submenu (works only for links of course).

  1. expect submenu with "send to some other firefox"
  2. submenu isn't rendered

There are two conditions where I can't find the submenu, and it's repeatable for me every time. It's only an issue with multiple displays.

  1. The context menu is cropped. If it's cropped enough to remove the '>' icon, the submenu doesn't appear.
  2. The context menu is very close to the screen edge, but rendered on the main display. The submenu should appear either left or on the second display, but it doesn't.

I managed to reproduce both cases with the current Nightly using the "Open Link in New Container Tab" entry.

Anyway, the cropped submenu issue and the two cases of submenus not being displayed are not part of this bug, so let's wait for Jan to decide what to do with these problems.

I reported the issue for Mutter here:
https://gitlab.gnome.org/GNOME/mutter/-/issues/1783

Added partial fix for the popup scaling. Does not fix the issue, because it's a problem in the mutter.

Pushed by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/376b32ae1255
Don't prefer scale of popup menu instead of shift; r=stransky

https://hg.mozilla.org/mozilla-central/rev/376b32ae1255

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
status-firefox90: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch

Thanks for the partial fix!

I am changing the resolution to MOVED because the remaining issues are bugs in Mutter which can be found via the above mentioned links. Also clearing the needinfo because I think there is nothing left to do on the Firefox side.

Flags: needinfo?(jhorak)
Resolution: FIXED → MOVED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: