1682136 - Window position not restored correctly on start (moved by 8px) when Session Restore is disabled

Status: REOPENED

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

Description

[the.recliner]

Attachment: Before and After Firefox Restart (top-left of the window)

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

Steps to reproduce:

1. Open Firefox (new installation, fresh profile).
2. Change the window size/position (without maximizing) and place the window at the leftmost of the screen (x=0).
3. Close Firefox (File > Quit, or the window's "X" button).
4. Open Firefox again (same profile).

Actual results:

The window is shifted by 8px to the right exactly. The width/height of the window are preserved, it only gets moved to the right.

The data in "xulstorage.json" when the window is closed at the leftmost:
[...]
"screenX": "-8",
"screenY": "0",
[...]

Once you re-open and close Firefox without moving it (after it was shifted on start):
[...]
"screenX": "0",
"screenY": "0",
[...]

The measured distance is effectively 8px as shown in the attached screenshots.

Expected results:

The window should have been restored exactly where it was before closing.

If I close Firefox and the window is on the rightmost of the screen Firefox shifts its window to the left by 8px exactly too.

If I manually set the window to the whole width of the screen (not with the maximize button), the window is shifted 8px to the right with a part of the window out of the bound of the screen.

If the window is not on the leftmost or rightmost, the position is restored correctly/precisely.

If the window is maximized, it is restored correctly (in its maximized state).

I have checked this behavior with other applications (Chrome, Discord, Microsoft Outlook/Word/Excel) and they all restore their size/position correctly, no shifting.

I have tried deleting xulstorage.json but the issue is still present, and it also happen on a fresh install/profile of Firefox (and Windows).

Tested on Firefox version: 83.0, Fresh Install and Profile
OS: Windows 10 20H2 (19042.685), Fresh Install, Default Display/Window Settings (Also tested on Windows Server 2016, same behavior).

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Arno Welzel]

I can confirm this with Firefox 87 in Windows 10.

The Window position and state is usually never restored correctly.

Comment 3

[Masatoshi Kimura [:emk]]

Looks like this is intentional:
https://searchfox.org/mozilla-central/rev/1758450798ae14492ba28b695f48143840ad6c5b/browser/components/sessionstore/SessionStore.jsm#4849-4863

"screenX": "-8",

This is because non-maximized window has a transparent border around the visible border on Windows 10.

Comment 4

[Masatoshi Kimura [:emk]]

Bug 1276516 is not a regressor, rather it should have fixed this.

Comment 5

[Masatoshi Kimura [:emk]]

I could not reproduce the bug...

Comment 6

[Masatoshi Kimura [:emk]]

This bug depends on the session restore setting (App menu > Options > General > Startup > Restore previous session).

If the session restore is enabled, the window will show at the wrong (shifted) position at first, then it will move to the correct (slightly off-screen) position. If the session restore is disabled, the window will stay at the wrong position.

Comment 7

[Masatoshi Kimura [:emk]]

I think ConstrainPosition will set the wrong initial position because the aAllowSlop argument is false:
https://searchfox.org/mozilla-central/rev/6c9ff2820d3aae683ec87c53c79e5108d54f3f76/xpfe/appshell/AppWindow.cpp#1307

Comment 8

[Masatoshi Kimura [:emk]]

Attachment: Bug 1682136 - Allow slop when the window position is persistent and it has no parent. r?nika

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/49744f943e16
Allow slop when the window position is persistent and it has no parent. r=xpcom-reviewers,nika

Comment 10

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/49744f943e16

Comment 11

[Natalia Csoregi [:nataliaCs]]

Backed out for putting browser window partially behind left and top taskbars on older Windows versions (bug 1705504)

backout: https://hg.mozilla.org/integration/autoland/rev/09908d752facc9c5ec5ddcc2e6fa33895a30070f

Comment 12

[Alexandru Michis [:malexandru]]

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/09908d752facc9c5ec5ddcc2e6fa33895a30070f

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

This got fixed by 1753836 - at least on my end. Please reopen the bug or comment if you can still reproduce the issue in the latest Nightly.

Comment 14

[Masatoshi Kimura [:emk]]

I can still reproduce this bug. Please make sure that Session Restore is disabled (as I wrote in comment #6).
Updating the title to clarify.

Comment 15

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

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:emk, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

Comment 16

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

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 17

[Suhaib Mujahid [:suhaib]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.