moz-regression led to bug 1809430

STR

• open Firefox in windowed mode and not tiled
• set always show bookmarks toolbar (mine is set to always show)
• close and reopen Firefox (or you can just nest new windows once set to get the same effect)
• note inner window size
  • e.g. console.log(window.innerHeight, window.innerWidth)
• click hamburger > new window, and note inner measurements of the new window

unexpected

• it keeps shrinking (also on app startup from last remembered info from I assume xulstore)

expected

• new windows or on app start, the window shouldn't shrink

notes

• In my case it shrinks 4px width and 32px height - and 32px is my exactly my bookmarks toolbar height. Tested with never show and the issue does not exist (didn't test with only show on new tab - I'm guessing it depends on the current focused tab's toolbar state when you hamburger a new window?)

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

:emilio, since you are the author of the regressor, bug 1809430, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

if you can't immediately replicate, you may need to close the new window and try it again for it to happen. I only diagnosed it a few hours ago, so I'm still working out the STR 100% reliably

I can reproduce the issue on Nightly111.0a1 Windows10.

STR

1. Disable Titlebar (by default)

2. Make sure sizemode is normal

3. To make the problem easily observable,
   Resize the window so that the bottom of the wallpaper is visible at least 100px.

4. Ctrl+N to open new window
   --- observe, The new window is smaller in height ---BUG！

5. Close the original window

6. Ctrl+N to open another new window
   --- observe, The new window is also smaller in height ---BUG！

Actual results:
The new window is smaller in height than the first window.

Expected:
Same height.

Disable Titlebar (by default)

that's interesting

To make the problem easily observable

yeah, just shrink the window and go for it with nested new windows

Make it take a const reference and simplify callers.

No behavior change, but noticed while looking through this code.

Sync the chromemargin attribute to the widget before restoring the
sizes, since the later depend on the former.

This is the same order we use when sizing the shell in OnChromeLoaded,
so it should be more consistent.

Depends on D168199

https://hg.mozilla.org/mozilla-central/rev/394f358959e3

https://hg.mozilla.org/mozilla-central/rev/52bc2423d62c

verified fixed

Backed out for causing for causing mochitest failures in toolkit/content/tests/chrome/test_maximized_persist_with_no_titlebar.xhtml

Backout link: https://hg.mozilla.org/integration/autoland/rev/5059c9a6a7335504026c1b21b6893b69c30315a7

Push with failures

Failure log

https://hg.mozilla.org/mozilla-central/rev/1b57be319580

I wonder if this might have fixed bug 1493472.

Reproduced the issue with Firefox 111.0a1 (2023-01-28) by following the STR from comment 3. Opening a new window will display a smaller window than the original one.
The issue is verified fixed with Firefox 111.0b8 on Windows 10x64, macOS 12, and Ubuntu 20.04. The newly opened window has the same weight and height as the original one after following STR from comment 3.