Firefox is opening window in the wrong screen
Categories
(Core :: Widget: Gtk, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox-esr91 | --- | unaffected |
firefox93 | --- | unaffected |
firefox94 | --- | unaffected |
firefox95 | --- | affected |
People
(Reporter: spl.bz, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(4 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0
Steps to reproduce:
I have a multimonitor system (three monitors, two Dell UP3219Qs and one Dell UP3216Q, which is configured as the center of the three monitors for 11520x2160 pixels and is set to be the "Primary Display") running under Ubuntu 21.04 and XFCE4 4.16 (aka Xubuntu).
Actual results:
With Nightly 95.0a1 (2021-10-07) (64-bit), when I open a new Firefox window, it appears at the far left screen, as opposed to the main (center) screen.
Expected results:
Previous versions of Firefox, until this evening's update (10/7/2021) opened the window on the main (center) screen. No other application on the system opens in other than the main window.
Please either restore the old behavior or give an option to do so for those of us who do not desire this feature.
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•3 years ago
|
||
Can you please use mozregression to find what broke it?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Use_Mozregression_tool
Thanks.
I've reverted back to 95.0a1 (2021-10-06) (64-bit) (2021-10-06).
This is what I get when I run mozregression:
mozregression --good 94.0a1 --bad 95.0a1
0:03.51 INFO: 95.0a1 is not a release, assuming it's a hash...
0:05.35 INFO: 94.0a1 is not a release, assuming it's a hash...
0:05.36 INFO: Getting mozilla-central builds between 94.0a1 and 95.0a1
0:06.79 ERROR: The url 'https://hg.mozilla.org/mozilla-central/json-pushes?changeset=94.0a1' returned a 404 error because the push is not in this repo (e.g., not merged yet).
I assume I've botched the arguments somehow. Please advise.
Comment 4•3 years ago
|
||
This should work: mozregression --good 94 --bad 95
mozregression --good 94 --bad 95
0:02.37 INFO: 95 is not a release, assuming it's a hash...
0:03.69 INFO: Using date 2021-10-04 for release 94
0:03.79 INFO: Getting mozilla-central builds between 2021-10-04 and 95
0:04.67 ERROR: The url 'https://hg.mozilla.org/mozilla-central/json-pushes?startdate=2021-10-04&tochange=95' contains no pushlog. Maybe use another range ?
Ah, figured out what it was trying to tell me:
mozregression --good 94 --bad 2021-10-07
[... lots of iterations ...]
3:25.65 INFO: Narrowed integration regression window from [2d978650, 1b7bfcae] (3 builds) to [2d978650, 1c581d24] (2 builds) (~1 steps left)
3:25.65 INFO: No more integration revisions, bisection finished.
3:25.65 INFO: Last good revision: 2d978650c932ee4951ce97d9e29da955f4a11cbf
3:25.65 INFO: First bad revision: 1c581d243b8752eef64ab15aca97e11afae39b67
3:25.65 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2d978650c932ee4951ce97d9e29da955f4a11cbf&tochange=1c581d243b8752eef64ab15aca97e11afae39b67
Updated•3 years ago
|
Comment 7•3 years ago
•
|
||
Just to make sure, that's X11 session, right?
Can you please run both (working and broken) version with MOZ_LOG="Widget:5" env variable and attach the log here?
Thanks.
This is the the log file from the working version. Note that I've reverted to the Developer edition 94.0b3 (64-bit) in order to keep the nag messages about upgrading from driving me insane until this is resolved.
This is the "non-working" log file, from 95.0a1 (2021-10-09) (64-bit).
Reporter | ||
Comment 10•3 years ago
|
||
I'm running X.Org version: 1.20.11 on an Ubuntu 21.04 installation. uname -a tells me
Linux george 5.11.0-37-generic #41-Ubuntu SMP Mon Sep 20 16:39:20 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
if that's at all of interest.
Reporter | ||
Comment 11•3 years ago
|
||
A bit of further information on the off chance it's useful:
xfwm4 --version
This is xfwm4 version 4.15.1git.UNKNOWN (revision UNKNOWN) for Xfce 4.16
Released under the terms of the GNU General Public License.
Compiled against GTK+-3.24.25, using GTK+-3.24.25.
Build configuration and supported features:
- Startup notification support: Yes
- XSync support: Yes
- Render support: Yes
- Xrandr support: Yes
- Xpresent support: No
- Embedded compositor: Yes
- Epoxy support: Yes
- KDE systray proxy (deprecated): No
loginctl show-session c2 -p Type
Type=x11
Updated•3 years ago
|
Comment 12•3 years ago
|
||
I see the working version is running in CSD mode while broken without decorations....did you set that?
Can you try to run firefox (broken) with GTK_CSD=1 env variable?
Do you have any custom rules for Firefox?
Updated•3 years ago
|
Comment 13•3 years ago
|
||
Set release status flags based on info from the regressing bug 1733620
Reporter | ||
Comment 14•3 years ago
|
||
The difference between the two versions in the logs may be because I ran the broken version from my laptop as an X client through SSH, since I have the Developer edition currently installed on my desktop machine. As I mentioned, I reverted to Developer edition on my desktop since the "update" popups were something of a nuisance.
If you'd like me to run Nightly on my desktop directly, I can do so. It's just a pain to keep profiles straight and I do have other work which I need to get done.
I'm not sure what you mean by "custom rules for Firefox." I have a whole slough of plugins and have fiddled with some settings in about:config. If you need that information, let me know.
The main reason I'm running a developer version of Firefox at all is that I have a couple of custom extensions I've written for my own personal use that probably have no value to anyone else and I didn't want to go through the rigamarole of getting the extensions "blessed". . . if that makes any sense to you.
Comment 15•3 years ago
|
||
Okay, can you reproduce that bug (or the old working behavior) with stock firefox binary locally?
Please use a new clean profile for it:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Test_Firefox_with_a_new_profile
Please test latest nightly and Firefox 93:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries
Thanks.
Comment 16•3 years ago
|
||
btw. the workspace management is here:
https://searchfox.org/mozilla-central/rev/0ec81de2037cb0a0701d5d316f42763230b3a142/widget/gtk/nsWindow.cpp#2696
Please try to set widget.workspace-management boolean variable at about:config and check if Firefox is restored on correct workspace.
Reporter | ||
Comment 17•3 years ago
|
||
As requested, I've run 95.0a1 from a fresh download of Nightly (15 Oct 2021 approx 10:30 AM PDT) with a fresh profile.
Comment 18•3 years ago
|
||
Bug 1735151 reverts the X11 widget code the state before Bug 1733620 so please test latest nightly when it lands (I expect tomorrow).
Reporter | ||
Comment 19•3 years ago
|
||
Nightly now acts as expected -- the window opens in my designated primary display.
Thanx.
Updated•3 years ago
|
Description
•