When opening Firefox, I can distinctly see the Firefox window being opened maximized, then getting quickly resized to smaller size and then maximized again. This only happens if session restore is enabled.

This sounds like something we'd already have a dupe of... are you familiar with a previous bug like this, mikedeboer?

Well, not really... there's bug 1376162, but it seems slightly different. Mike, while you're here, why is it that the windows animate to their new sizes? Wasn't that supposed to be disabled, or is that only when you open a new window with fixed dimensions? If so, would it be difficult to programmatically disable this resize animation whilst restoring window features?

Marco, could you perhaps post a short video of this behavior? That way I can see which OS, window manager and other details right away. Thanks in advance!!

This is on Windows, with a more or less default configuration. I'll try to take a video later today (not sure if the machine is powerful enough to take it at a rate that would show the problem). On Linux, I see a different (but maybe related?) bug (I'm attaching a screenshot). The window is maximized, then quickly resized, then maximized again (but the resulting window has visual artifacts). Note this is on a completely different machine and on a clean profile.

(In reply to Mike de Boer [:mikedeboer] from comment #2) > Mike, while you're here, why is it that the windows animate to their new > sizes? Wasn't that supposed to be disabled, or is that only when you open a > new window with fixed dimensions? > If so, would it be difficult to programmatically disable this resize > animation whilst restoring window features? Looks like we try to suppress window animations here: https://searchfox.org/mozilla-central/rev/08df4e6e11284186d477d7e5b0ae48483ecc979c/browser/components/sessionstore/SessionStore.jsm#4177 Am I correct in that this is the codepath we go through when restoring a window's features?

Right, that is correct. It just doesn't seem like that's working for `resizeTo()`[1] on OSX. [1] https://searchfox.org/mozilla-central/rev/08df4e6e11284186d477d7e5b0ae48483ecc979c/browser/components/sessionstore/SessionStore.jsm#4189

(In reply to Mike de Boer [:mikedeboer] from comment #6) > Right, that is correct. It just doesn't seem like that's working for > `resizeTo()`[1] on OSX. > > [1] > https://searchfox.org/mozilla-central/rev/ > 08df4e6e11284186d477d7e5b0ae48483ecc979c/browser/components/sessionstore/ > SessionStore.jsm#4189 Yeah, on reflection, that's pretty odd. When I open the Browser Console and manually call window.resizeTo, I get 0 transition every time. Same thing if the window has just been opened, using something like: let w = OpenBrowserWindow(); w.resizeTo(500, 500); So there must be something kind of special about these windows that are transitioning during restore... or, at least, something special about our state.

Here's the video. You can see the transition around ~3-4 seconds in.

Ah, okay. That's two windows, right? That second window doesn't appear to be animating - but we do seem to open it, paint a frame, and then resize it.

(In reply to Mike Conley (:mconley) (:⚙️) (Totally backlogged on reviews and needinfos) from comment #9) > Ah, okay. That's two windows, right? That second window doesn't appear to be > animating - but we do seem to open it, paint a frame, and then resize it. No, it is a single window.

If this hasn't happened to you before, it might just be a regression from bug 1034036.

(In reply to Mike de Boer [:mikedeboer] from comment #11) > If this hasn't happened to you before, it might just be a regression from > bug 1034036. It looks like it landed after I filed this bug.

Marco, can you clarify a bit - I don't really see any issues myself on Windows or mac, and both the screenshot and the video look like they're from Linux, (though comment 4 says the screenshot is from Windows?) and at least to me look like graphics glitches (rather than the window size actually changing). Can you reproduce in safe mode? Clean profile? Or "only" on your regular profile? If it's a recent regression, can you try figuring out what regressed this using mozregression? That'd really help in narrowing down what's going on here given that it doesn't seem to be universally reproducible.

I think it actually _is_ universally reproducible (Marco, please correct me if I'm wrong in the following): STR: 1. Enable 'When Firefox starts (*) Show your windows and tabs from last time' in about:preferences, 2. Resize the window and put it someplace else, 3. Exit Firefox and restart. ER: Debatable, but the window should show up and be at its correct position and size immediately. AR: The window shows up at the default position and its default size (OS determined, I think) and only corrects the position & size once session restore kicks in later. This results in a jump and flicker.

I say 'debatable', because it's in fact a goal to show the first window as quickly as possible and not wait for sessionstore to initialize first, meaning that performance would definitely regress if we were to somehow make sessionstore initialize synchronously to get the window properties before showing anything.

(In reply to :Gijs (he/him; out 3-8 May) from comment #13) > Marco, can you clarify a bit - I don't really see any issues myself on > Windows or mac, and both the screenshot and the video look like they're from > Linux, (though comment 4 says the screenshot is from Windows?) Sorry, to clarify, the bug I filed here is about Windows, the screenshot is from Linux (where I see a problem that might or might not be related). The video is from Windows. > and at least > to me look like graphics glitches (rather than the window size actually > changing). No, it's the window size changing, you can see it if you play the video frame by frame. I'm attaching a frame of the video where this is clearly visible. > Can you reproduce in safe mode? Clean profile? Or "only" on your > regular profile? If it's a recent regression, can you try figuring out what > regressed this using mozregression? That'd really help in narrowing down > what's going on here given that it doesn't seem to be universally > reproducible. I'll try. (In reply to Mike de Boer [:mikedeboer] from comment #14) > I think it actually _is_ universally reproducible (Marco, please correct me > if I'm wrong in the following): > > STR: > 1. Enable 'When Firefox starts (*) Show your windows and tabs from last > time' in about:preferences, > 2. Resize the window and put it someplace else, > 3. Exit Firefox and restart. > > ER: > Debatable, but the window should show up and be at its correct position > and size immediately. > > AR: > The window shows up at the default position and its default size (OS > determined, I think) and only corrects the position & size once session > restore kicks in later. This results in a jump and flicker. I'm not resizing the window, the window is maximized when I close Firefox and is maximized at the end of startup. The bug is that the window starts as maximized, then gets resized to a smaller size, then gets maximized again.

(In reply to Marco Castelluccio [:marco] from comment #16) > > and at least > > to me look like graphics glitches (rather than the window size actually > > changing). > > No, it's the window size changing, you can see it if you play the video > frame by frame. I'm attaching a frame of the video where this is clearly > visible. FWIW, for me the fact that there's a sliver of the "correct" window contents (ie a bit of the middle of the URL bar) on the left-hand side of the "shifted" window frame, and that the remaining part of the screen is white (rather than desktop background or some other window that was behind the Firefox window), and that there is a small grey border at the top even next to the new "edge" of the window is what makes me think this is a graphics glitch, rather than the actual window size changing. Hard to be sure without being able to reproduce, though... > > Can you reproduce in safe mode? Clean profile? Or "only" on your > > regular profile? If it's a recent regression, can you try figuring out what > > regressed this using mozregression? That'd really help in narrowing down > > what's going on here given that it doesn't seem to be universally > > reproducible. > > I'll try. > > (In reply to Mike de Boer [:mikedeboer] from comment #14) > > I think it actually _is_ universally reproducible (Marco, please correct me > > if I'm wrong in the following): > > > > STR: > > 1. Enable 'When Firefox starts (*) Show your windows and tabs from last > > time' in about:preferences, > > 2. Resize the window and put it someplace else, > > 3. Exit Firefox and restart. > > > > ER: > > Debatable, but the window should show up and be at its correct position > > and size immediately. > > > > AR: > > The window shows up at the default position and its default size (OS > > determined, I think) and only corrects the position & size once session > > restore kicks in later. This results in a jump and flicker. This is about restored windows, and I'd expect some issues there with multiple windows because we persist *1* sizemode (ie restored/maximized/fullscreen) and size/position separately from whatever sessionstore does. But the steps from comment 0 and the one that follow in Marco's quoted comment below should work without issue, because the sizemode of the window stays the same - the XULStore value is a maximized window, so that's how we open the window, and then the sessionstore value is presumably also a maximized window, so presumably that should just no-op. And presumably, because comment #0 says "the window", there is only 1 window... > I'm not resizing the window, the window is maximized when I close Firefox > and is maximized at the end of startup. The bug is that the window starts as > maximized, then gets resized to a smaller size, then gets maximized again. Yeah, I can't reproduce this, even after trying several variations (with/without profile manager, clean profile, used profile, etc.). :-( To be really clear, I definitely agree that there's an issue in the screencast and in the frame and in the other, Linux screenshot. I'd just like to track down exactly what the issue is (or issues are) and how to reproduce it so we can get it fixed.

(In reply to :Gijs (he/him; out 3-8 May) from comment #18) > (In reply to Marco Castelluccio [:marco] from comment #16) > > > and at least > > > to me look like graphics glitches (rather than the window size actually > > > changing). > > > > No, it's the window size changing, you can see it if you play the video > > frame by frame. I'm attaching a frame of the video where this is clearly > > visible. > > FWIW, for me the fact that there's a sliver of the "correct" window contents > (ie a bit of the middle of the URL bar) on the left-hand side of the > "shifted" window frame, and that the remaining part of the screen is white > (rather than desktop background or some other window that was behind the > Firefox window), and that there is a small grey border at the top even next > to the new "edge" of the window is what makes me think this is a graphics > glitch, rather than the actual window size changing. Hard to be sure without > being able to reproduce, though... The video unfortunately doesn't show you, but in the area you see white I actually see the desktop content.

This is a regression from bug 1439875. Could you look into it?

Which platform is this on? Windows I pressume?

Yes, Windows. There's a problem on Linux too, but it might or might not be the same problem, so I would consider Windows only.

If it's any help, it happens to me regardless if I have session restore enabled or not. Also, sometimes the browser starts maximized then switch to a smaller window then maximized again and some other times it just start maximized then switch to a smaller window and gets stuck in this state until I maximize it again. Didn't found a pattern to always get the same result.

Do you have privacy.resistFingerprinting enabled?

Sorry for the delay, I didn't have access to the machine. I don't have privacy.resistFingerprinting enabled.

Hi Emilio, I think :marco asked you to take a look at this since this is a regression from bug 1439875. Did this slip off your radar, perhaps?

Yes, it did, sorry! I'm setting up a windows thingie right now actually, so should be able to diagnose and fix hopefully. Taking for now, will report back if I don't figure out.

Emilio, do you have an update on this one? Thanks

Happy to take a patch in nightly; if it seems low risk enough please feel free to request uplift to 65 beta.