1866583 - Firefox windows reopened at session start are not positioned where they were closed

Status: RESOLVED FIXED

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

Description

[Pean LIM]

Attachment: 2023-11-24 13_53_24-Greenshot.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

Tried to use the "Move newly created windows to their last known zone" feature in the FancyZones utility in Microsoft PowerToys v 0.75.1 (and also v 0.72.0)
Running on Win10Pro build 22H2, Firefox ESR 115

Actual results:

The newly created Firefox window did open in the correct zone, and with the correct size, but was slight displaced in both the horizontal and vertical axes (see screenshot attached).

Expected results:

The Firefox should have been positioned to exactly fill the left half of the desktop, which was where it was when last used.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Pean LIM]

On further observation, this may not be a PowerToys/FancyZones bug. Even without PowerToys utilities running, Firefox has the same issue--it tries but does not quite manage to open the window to the last location.

Comment 3

[Ray Kraesig [:rkraesig]]

That's potentially worth reprioritizing, then.

If you move Firefox with PowerToys not active (perhaps via Win+Left or Win+Right) and then close it, does it reopen in the correct position? That is, is the intervention of FancyZones (or some other tool) required to put Firefox in a bad state?

Comment 4

[Pean LIM]

Tested with Win+Left (& also Win+Right). FancyZones is not required to put Firefox in a bad state.

Comment 5

[Ray Kraesig [:rkraesig]]

(In reply to Pean LIM from comment #4)

Tested with Win+Left (& also Win+Right). FancyZones is not required to put Firefox in a bad state.

Thanks! I can reproduce this in ESR 115, but it seems to be fixed in the current Release build (v120).

Comment 6

[Pean LIM]

Glad to hear the bug is reproducible in ESR 115, and that is fixed in current Release build. I look forward to seeing the fix in the next ESR (assuming that would be based on a current release version no less than v120). Thank you.

Comment 7

[Ray Kraesig [:rkraesig]]

Yes — the current plan is to branch the next ESR from v128 next month (https://whattrainisitnow.com/release/?version=esr), although I'm admittedly not sure how our releases work while the base version is in Nightly.

It may be worthwhile to confirm that it's also fixed on your system by installing the latest Nightly version, though. (This shouldn't affect your existing ESR installation.)

Comment 8

[Skuva]

What is the status on this fix? I'm already at ESR 128.4 and still having the problem (with Nightly too).

Comment 9

[Ray Kraesig [:rkraesig]]

The status is "we were completely unaware that this was still a problem on mainline Firefox".

On review, I suspect what may have happened was that a similar bug was introduced. Testing it now (132.0.2) yields the interesting behavior that the skeleton UI is positioned correctly, but once the Firefox UI proper appears, the window moves. This happens either with FancyZones or after Win+Right.

Comment 10

[Ray Kraesig [:rkraesig]]

Attachment: Bug 1866583 - [1/4] Remove nsWindow::GetHeight r?#win-reviewers

nsWindow::GetHeight() was devirtualized in bug 594977 (2010-11-08),
and the last bit of its interesting functionality was removed in bug
473687 (2011-04-24).

Comment 11

[Ray Kraesig [:rkraesig]]

Attachment: Bug 1866583 - [2/4] Add nsWindow::ConstrainPositionToBounds r?#win-reviewers!,#mac-reviewers!,stransky,emilio

Unify behavior across platforms by introducing a new auxiliary function,
nsWindow::ConstrainPositionToBounds.

No functional changes (yet).

Comment 12

[Ray Kraesig [:rkraesig]]

Attachment: Bug 1866583 - [3/4] Skip repositioning the window if it may have been snapped r?#win-reviewers

If a window appears to be being restored to a position matching what we
know of Aero Snap (which is underdocumented and which Microsoft has
provided no APIs with which to interface), leave it in place in
nsWindow::ConstrainPosition.

Comment 13

[Ray Kraesig [:rkraesig]]

Attachment: Bug 1866583 - [4/4] Ensure windows are not moved offscreen by `ConstrainPositionToBounds` r?#win-reviewers!,#mac-reviewers!,emilio,stransky

Address a more general potential cross-platform misbehavior: if a window
is too large for the current screen, it will usually be inconveniently
moved offscreen to the upper left, with only the lower-right corner
visible. Reverse that.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/96c2bed433c4
[1/4] Remove nsWindow::GetHeight  r=emilio
https://hg.mozilla.org/integration/autoland/rev/fdd451ed5f4c
[2/4] Add nsWindow::ConstrainPositionToBounds  r=stransky,emilio,win-reviewers,mac-reviewers,handyman,spohl
https://hg.mozilla.org/integration/autoland/rev/8b0cf65c5bfb
[3/4] Skip repositioning the window if it may have been snapped  r=win-reviewers,handyman
https://hg.mozilla.org/integration/autoland/rev/aba73896879d
[4/4] Ensure windows are not moved offscreen by `ConstrainPositionToBounds`  r=emilio,win-reviewers,mac-reviewers,handyman,spohl
https://hg.mozilla.org/integration/autoland/rev/e174d577689a
apply code formatting via Lando

Comment 15

[amarc]

https://hg.mozilla.org/mozilla-central/rev/96c2bed433c4
https://hg.mozilla.org/mozilla-central/rev/fdd451ed5f4c
https://hg.mozilla.org/mozilla-central/rev/8b0cf65c5bfb
https://hg.mozilla.org/mozilla-central/rev/aba73896879d
https://hg.mozilla.org/mozilla-central/rev/e174d577689a