2076558 - Firefox opens windows on the wrong monitor since 157.0 (Regression)

Status: VERIFIED FIXED

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

Description

[Matt Keenan]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:157.0) Gecko/20100101 Firefox/157.0

Steps to reproduce

Open whisker menu (XFCE) on monitor 2, click Firefox menu option

Mozilla/5.0 (X11; Linux x86_64; rv:157.0) Gecko/20100101 Firefox/157.0
Linux 7.0.0-34-generic #34~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 4 15:38:29 UTC 2

Actual results

Firefox opens window on monitor 1

Expected results

Prior to Firefox 157.0 the Firefox window would open on the active monitor, not monitor 1

Prior to Firefox 157.0 / Bug 2070008 / commit 7fb2bbfc8936 there was a #if defined(XP_UNIX) && !defined(XP_MACOSX) statement that ignored the saved XUL position. This is no longer the case so Firefox will open on which ever monitor it last saved its XUL position.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

Some questions:

• Do you have session restore enabled? I.e. "Open previous windows and tabs" in about:preferences.
• This is X11, right? (Just confirming, I think XFCE gained some wayland support recently-ish?)

Iff the answer to the previous questions is "yes", then does moving the window to monitor 2 manually, closing it, and doing the same keep the window in the right place?

I.e., are we restoring the window position correctly, or is it moved to the wrong monitor or somesuch regardless of where it used to live?

Comment 2

[Matt Keenan]

Thanks for picking this up so quickly.

• I do not have session restore enabled
• Yes, this is X11; I haven't got around to upgrading to 26.04, X11 is the only option for XFCE 4.18

w.r.t. keeping the window in the right place, I use multiple workspaces; on some workspaces I keep Firefox on the left, others on the right, and some on both monitors. So my workflow until now was the WM would size Firefox correctly but always on the active monitor, that's the bit that's not working now, placement on the active window. So for my use case having Firefox remember the right size is fine, having it remember which monitor is not.

Hopefully this makes sense. For the moment I'm using overrides which obviously includes flickering because Firefox isn't moved to the active monitor until after it is mapped (window_open).

Comment 3

[Matt Keenan]

Sorry, I just realised, when I said "that's not working now, placement on the active window" that was a mistake, what I meant was "that's not working now, placement on the active monitor".

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Does it work if you go to about:config and set browser.sessionstore.restore_windows_to_virtual_desktop to false?

Comment 5

[Matt Keenan]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #4)

Does it work if you go to about:config and set browser.sessionstore.restore_windows_to_virtual_desktop to false?

No, still the same, mind you that's without a Firefox restart. I'll check again in the morning, but right now I have too many windows with work I have to finish up.

Comment 6

[Matt Keenan]

So I restarted Firefox with restore_windows_to_virtual_desktop set to false and it's still opening on the wrong monitor. Closing Firefox on the second monitor and then opening Firefox again on the second monitor still opens on the first monitor.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Please run with MOZ_LOG="Widget:5", reproduce it and attach the log here (it possible). If you launch it from a system menu you'd need to add to startup shell somewhere MOZ_LOG="Widget:5" MOZ_LOG_FILE=something reproduce the issue and then attach the log file from MOZ_LOG_FILE here. (may be for instance MOZ_LOG_FILE=/home/your_username/log.txt or so)

Comment 8

[Matt Keenan]

I ran it with the MOZ_LOG and MOZ_LOG_FILE and the logs appear to be "content free"

matt@foobox:~$ MOZ_LOG="Widget:5" MOZ_LOG_FILE=/tmp/bug-moz-2076558-widget-5.log firefox
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
matt@foobox:~$ vi /tmp/bu
bug-moz-2076558-widget-5.log.child-1.moz_log
bug-moz-2076558-widget-5.log.moz_log
matt@foobox:~$ vi /tmp/bug-moz-2076558-widget-5.log.moz_log 
matt@foobox:~$ vi /tmp/bug-moz-2076558-widget-5.log.child-1.moz_log 
matt@foobox:~$ cat /tmp/bug-moz-2076558-widget-5.log.moz_log
[Parent 12955: Main Thread]: D/Widget nsAppShell::Observe() topic xpcom-shutdown
matt@foobox:~$ cat /tmp/bug-moz-2076558-widget-5.log.child-1.moz_log
[Socket 13004: Main Thread]: D/Widget nsAppShell::Observe() topic xpcom-shutdown

Comment 9

[Luke Bratch [:l_bratch]]

Attachment: foo.txt.moz_log

I'm having the same problem with Firefox 157.0 running in Fluxbox on X11. The problem occurs both when opening a new Firefox instance, and when opening a new window from an already-running Firefox instance.

Previously new windows would follow the window manager behaviour, which in Fluxbox's case is to appear on the monitor where the mouse is. Now new windows always appear on the same monitor. Why a particular monitor is chosen is not yet clear.

Here is the output of MOZ_LOG="Widget:5" when launching Firefox and opening a few new windows with the mouse on different monitors.

Comment 10

[Simon]

Windows n+1 are also not positioned by the WM (Xfwm) anymore!
Prior to 157 new windows would open according to its smart placement logic in a free area, effectively putting them side-by-side.
Now they just stack a few pixels to the side of the old window, which is rather useless.

Comment 11

[Martin Stránský [:stransky] (ni? me)]

Emilio, the bug looks valid. We move the window to particular position before we call maximize:

[Parent 189129: Main Thread]: D/Widget [7fe139e38f00]: nsWindow::Move to [2613 x 83] scale 1.000000 scaled [2613.00 x 83.00]
[Parent 189129: Main Thread]: D/Widget [7fe139e38f00]:   bounds 0 x 0
[...]
[Parent 189129: Main Thread]: D/Widget [7fe139e38f00]: nsWindow::SetSizeMode 2
[Parent 189129: Main Thread]: D/Widget [7fe139e38f00]:     set maximized

On X11 move-to x=2613 on 1900 wide monitor means the window is move to right monitor.

UpdateWindowStateFromMiscXULAttributes(); sets ignore-move for maximized windows but we moved the window already before

  bool positionSet =
      !mIgnoreXULPosition && LoadPositionFromXUL(specWidth, specHeight);   // ~line 2445
  ...
  if (positionSet) {
    LoadPositionFromXUL(specWidth, specHeight);                           // ~line 2459
  }

Comment 12

[BugBot [:suhaib / :marco]]

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

Comment 13

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2076558 - Don't constrain position if we didn't get any. r=smaug,stransky

Otherwise on some environments we do a move before mapping the window
which prevents the DE's placement.

Note that this is necessary but not sufficient to actually fix the issue
as reported, because browser.xhtml does specify screen{X,Y}. I'll look
into that as well, specially into how this works on Windows.

Comment 14

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2076558 - Don't specify screen{X,Y} in browser.xhtml. r=#firefox-desktop-core-reviewers

So that it uses the position the window manager chooses instead.

Comment 15

[Emilio Cobos Álvarez [:emilio]]

I just checked, and turns out Windows has basically the same issue afaict...

Comment 16

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2076558 - Disable LoadPositionFromXUL on GTK at runtime. r=stransky

See the comments for reasoning. This effectively restores the previous
behavior, but leaves a runtime switch to take the Windows/macOS path.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/797520c8e5b0
https://hg.mozilla.org/integration/autoland/rev/d69b3c2d6987
Don't constrain position if we didn't get any. r=smaug

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/79a57e65101e
https://hg.mozilla.org/integration/autoland/rev/f666620ab79a
Disable LoadPositionFromXUL on GTK at runtime. r=stransky

Comment 20

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/d69b3c2d6987
https://hg.mozilla.org/mozilla-central/rev/f666620ab79a

Comment 21

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.

:emilio, please make an uplift decision for beta:

• For beta, nominate the patch for beta uplift approval if the fix should be included in this release, or set status-firefox158 to wontfix if the fix can wait for the next release.

See Requesting an Uplift for documentation on how to request an uplift.

For more information, please visit BugBot documentation.

Comment 22

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Restores previous behavior for now.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: Restores previous behavior.
• String changes made/needed?: none
• Is Android affected?: no

Comment 23

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2076558 - Disable LoadPositionFromXUL on GTK at runtime.

See the comments for reasoning. This effectively restores the previous
behavior, but leaves a runtime switch to take the Windows/macOS path.

Original Revision: https://phabricator.services.mozilla.com/D330938

Comment 24

[Dianna Smith [:diannaS]]

Comment on attachment 9655185 [details]
Bug 2076558 - Disable LoadPositionFromXUL on GTK at runtime.

moving flag to release for consideration for the 158 dot release

Comment 25

[Performance Sheriff Bot]

Perfherder has detected a browsertime performance change from push f666620ab79a0d279e7e24e66a868983959f83dc.

No action is required from the author; this comment is provided for informational purposes only.

Improvements	Test	Platform	Options	Absolute values [old vs new]	Performance Profiles
26%	outlook LastVisualChange (doc)	macosx1470-64-shippable	fission warm webrender	1,617.32 ms -> 1,192.47 ms
18%	paypal fcp (doc)	macosx1470-64-shippable	fission warm webrender	101.30 ms -> 82.80 ms
6%	wikipedia LastVisualChange (doc)	macosx1500-aarch64-shippable	cold fission webrender	352.81 ms -> 331.15 ms
4%	wikipedia PerceptualSpeedIndex (doc)	macosx1500-aarch64-shippable	fission warm webrender	185.06 ms -> 177.44 ms
4%	wikia SpeedIndex (doc)	linux2404-64-shippable	fission warm webrender	395.07 ms -> 379.85 ms	Before/After
...	...	...	...	...	...
2%	matrix-react-bench (doc)	linux2404-64-shippable	fission webrender	20.06 ms -> 19.58 ms

Need Help or Information?

If you have any questions, please reach out to [e-mail]. Alternatively, you can find help on Slack by joining #perf-help, and on Matrix you can find help by joining #perftest.

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.

Comment 26

[Emilio Cobos Álvarez [:emilio]]

I don't think there's a way this could've improved the macOS tests.

Comment 27

[Jens Stutte [:jstutte]]

There is some overlap of the alert with bug 2051892.

The macOS entries here, the Speedometer 3 subtests, bing-search LCP and the Linux wikia SpeedIndex step at push 2058940, which is bug 2051892 (timer thread changes) landing just before this bug's push, inside the same alert range. Per-push medians for mac Speedometer 3 NewsSite-Nuxt, for example: 35.12 before, 35.39 at bug 2051892, 35.45 at this bug. Only linux matrix-react-bench steps at this bug's push (20.0 to 19.45). The pageload improvements from comment 25 were already reassigned to alert summary 53348, which covers the same range.

Comment 30

[Acasandrei Beatrice (needinfo me)]

Thank you for catching the error regarding the macOS alerts. I have updated the alerts summary to reflect the correct improvements.

Improvements	Test	Platform	Options	Absolute values [old vs new]	Performance Profiles
4%	wikia SpeedIndex (doc)	linux2404-64-shippable	fission warm webrender	395.07 ms -> 379.85 ms	Before/After
4%	wikia SpeedIndex (doc)	linux2404-64-shippable	cold fission webrender	670.15 ms -> 646.11 ms	Before/After
3%	wikia PerceptualSpeedIndex (doc)	linux2404-64-shippable	cold fission webrender	609.11 ms -> 593.66 ms	Before/After
2%	matrix-react-bench (doc)	linux2404-64-shippable	fission webrender	20.06 ms -> 19.58 ms

Comment 31

[Negritas Sergiu, Desktop QA]

Hello I can confirm that the issue is fixed with firefox 159.0b1 on Ubuntu 24.04 on XFCE with a dual monitor settup.

I will update the flags and status of this issue.

Have a nice day!

Comment 32

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/9c65c6aa1f94
https://hg.mozilla.org/releases/mozilla-release/rev/5f1d66b6cf51

Comment 33

[Negritas Sergiu, Desktop QA]

Hello! I can confirm that the issue is fixed with firefox 158.0.1 on Ubuntu 24.04 on XFCE with a dual monitor setup.

I will update the flags accordingly.

Have a nice day!