Closed Bug 1734758 Opened 3 years ago Closed 3 years ago

Firefox is opening window in the wrong screen

Categories

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

Firefox 95
defect

Tracking

()

RESOLVED DUPLICATE of bug 1735151
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.

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.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Flags: needinfo?(spl.bz)

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.

Flags: needinfo?(spl.bz)

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

Regressed by: 1733620
Has Regression Range: --- → yes

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.

Flags: needinfo?(spl.bz)
Attached file working.log

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.

Attached file borked.log

This is the "non-working" log file, from 95.0a1 (2021-10-09) (64-bit).

Flags: needinfo?(spl.bz)

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.

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

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?

Flags: needinfo?(spl.bz)
Priority: -- → P2

Set release status flags based on info from the regressing bug 1733620

Attached file 10-12-2021.log

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.

Flags: needinfo?(spl.bz)

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.

Flags: needinfo?(spl.bz)

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.

Attached file no_profile.log

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.

Flags: needinfo?(spl.bz)

Bug 1735151 reverts the X11 widget code the state before Bug 1733620 so please test latest nightly when it lands (I expect tomorrow).

Nightly now acts as expected -- the window opens in my designated primary display.

Thanx.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: