Menus broken when second monitor disconnected
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: ant, Unassigned)
References
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:150.0) Gecko/20100101 Firefox/150.0
Steps to reproduce:
- Connect a second monitor, configure it to be to the LEFT of the primary monitor (important).
- Launch Firefox, verify the menus work (hamburger menu, right-click menu)
- Disconnect the second monitor. All windows including Firefox will move to the primary.
- Verify that menus are now broken.
Actual results:
Menus work when there are no additional monitors, or when the primary monitor is to the left. If the secondary monitor is to the left, then menus stop displaying when the secondary monitor is disconnected.
If the secondary monitor is reconnected, menus work again. If the secondary monitor is moved to the right of the primary, then menus work again.
Expected results:
Menus should work at all times, regardless of monitor layout and state.
Debian 13, default desktop install, running GNOME on Wayland. This has been verified in the Flatpak version of Firefox 150, and also the downloaded .tar.xz version of 150.
Comment 2•4 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Could you try this build?
Unfortunately the issue is still present in the build provided.
Comment 5•4 months ago
|
||
Please run on terminal with MOZ_LOG="WidgetScreen:5" env variable, reproduce the issue and attach the log here.
Thanks.
Please find the log attached. However, there is a twist!
The menus in the Nightly build worked fine when launching Firefox from the command line, with or without the MOZ_LOG environment variable. But when I launched the Firefox binary from Nautilus, the menus are broken.
To try to capture the environment variables without using the Terminal, I created a basic .desktop file calling the nightly build. If I include the --MOZ_LOG and --MOZ_LOG_FILE arguments, the menus work fine. If I do not include those arguments, the menus are broken.
The only environment variable I have permanently set related to Firefox is MOZ_ENABLE_WAYLAND=1.
The desktop file I used, for reference, is below:
[Desktop Entry]
Name=Firefox Nightly
Comment=Browse the World Wide Web
GenericName=Web Browser
X-GNOME-FullName=Firefox Nightly Web Browser
TryExec=/home/ant/opt/firefox/firefox
#Exec=/home/ant/opt/firefox/firefox --MOZ_LOG="WidgetScreen:5" --MOZ_LOG_FILE=/home/ant/nightly.log %u
Exec=/home/ant/opt/firefox/firefox %u
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=/home/ant/opt/firefox/browser/chrome/icons/default/default128.png
Categories=Network;WebBrowser;
MimeType=text/html;text/xml;application/xhtml+xml;application/xml;application/vnd.mozilla.xul+xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png;x-scheme-handler/http;x-scheme-handler/https;
StartupWMClass=firefox
StartupNotify=true
Just to clarify, because of the above, the log is from when the menus were working. I was not able to reproduce the issue while also capturing log output.
Could you provide "about:support" for both from command line and from Nautilus?
| Reporter | ||
Comment 10•4 months ago
|
||
| Reporter | ||
Comment 11•4 months ago
|
||
| Reporter | ||
Comment 12•4 months ago
|
||
I have uploaded the output from about:support for both launch methods.
Comment 13•4 months ago
|
||
Does it work in earlier version, ex. 149?
Could you run mozregression to help us to identify the root cause if it works with 149 or earlier.
Comment 14•3 months ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has recent activity, could you have a look please?
For more information, please visit BugBot documentation.
Updated•3 months ago
|
Description
•