STR:

1. Ctrl+N to create a new window.
   (Note: for me, this window is automatically maximized, and the bug only reproduces if the window is maximized. If you're trying to repro, consider maximizing the window if it's not already.)

2. Ctrl+W to close that new window.

3. Ctrl+Shift+N to recreate that new window.

ACTUAL RESULTS:
The recreated window is extremely small and looks clipped.

EXPECTED RESULTS:
Properly sized window.

Note: as noted under (1): for me, new Firefox windows are automatically maximized (including in a fresh profile and e.g. in mozregression-launched Firefox). I suspect that's a system configuration thing, maybe via Wayland? It seems to be required

Here's a screencast showing the bug, using today's Nightly (2023-02-14) which I'm launching via mozregression.

I open a new window at around 0:15-0:16 in the screencast.
I close that window at 0:18.
I reopen that window with Ctrl+Shift+N at 0:19, and it's glitched / small.

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4b2e3689cea010e9473792bd8f5a8606c862e09d&tochange=7966f6606190515258c3f19ad4d05ed4d317f164

--> regression from bug 1804295

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

This is linux, correct? All the platforms do window sizing in so different ways that platform is rather important to know.

Do you happen to use some a bit older wayland? I used to see badly sized windows all the time still last autumn before I updated for Fedora 36.
Basically always when restoring a FF session with multiple windows, always couple of them had too small size. I think there is an existing bug about that.
I haven't seen that issue anymore recently.

(In reply to Daniel Holbert [:dholbert] from comment #0)

STR:

1. Ctrl+N to create a new window.
   (Note: for me, this window is automatically maximized, and the bug only reproduces if the window is maximized. If you're trying to repro, consider maximizing the window if it's not already.)

Just confirming this -- on a different system with a larger display, where the window is not automatically maximized, I can still reproduce this bug if I maximize the new window after step 1.

(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #4)

This is linux, correct? [...] Do you happen to use some a bit older wayland?

Yes, this is Ubuntu 22.04. I've got whatever the stock wayland version is there, which seems to be 1.20, based on apt list --installed | grep libwayland-bin (that seems to be one of the core wayland packages?), which gives me libwayland-bin/jammy-updates,jammy-security,now 1.20.0-1ubuntu0.1 amd64 [installed,automatic].

(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #5)

Basically always when restoring a FF session with multiple windows, always couple of them had too small size. I think there is an existing bug about that.
I haven't seen that issue anymore recently.

I know the exact issue; I also used to hit it all the time (even without Wayland I think), specifically when session-restoring Firefox. I haven't hit it in a while either, and I'm not hitting it currently when I start/restart Firefox. But this does feel like a manifestation of a similar issue.

I do see that too on Gnome / Fedora 34, usually after workspace switch or resume from locked state. Affects other applications too (terminal for instance) so looks like mutter / Gnome bug to me.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)

I do see that too on Gnome / Fedora 34, usually after workspace switch or resume from locked state. Affects other applications too (terminal for instance) so looks like mutter / Gnome bug to me.

That's interesting -- I haven't seen this in other apps. Though, note that the STR here don't involve any such OS-level interaction (workspace switching or resuming). This reliably reproduces for me when I simply do "undo-close-window" for a maximized window.

For comparison, Chrome and pre-regression-range Firefox don't reproduce this undo-close-window problem.