1943805 - Firefox resets window size with every new window

Status: RESOLVED INVALID

(Firefox :: Session Restore, defect)

Description

[joemcken64]

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

Steps to reproduce:

Launch Firefox. Or open a new Firefox window. Or take a tab from one window and split it off into its own window.

Actual results:

Every new window opens at a preset size of 1414×993, regardless of any custom size that was previously set by the user.

When a window is resized (by clicking the border and dragging to the desired size), Firefox is closed, and then relaunched, the new window briefly flickers at its designated custom size, but immediately resets to the new size of 1414×993.

When a window is set to a custom size, it remembers its size as long as it stays open, even when maximizing/restoring down/minimizing/full-screening/etc.
But the moment it is closed and a new window is opened, its size is reset to 1414×993.

Expected results:

Firefox should remember the last set custom size for new windows, as it has always done until update v134.0.2.

Comment 1

[joemcken64]

Can’t figure out how to edit my initial post above, so adding here: I tried deleting “xulstore.json” from my browser profile, which changed nothing. I then tried running Firefox in Troubleshoot Mode to try with all settings & plugins reset, yet this also did nothing; the issue persisted.

Comment 2

[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 3

[joemcken64]

Update: Since filing this bug report, I had to perform a System Restore due to an unrelated issue with Windows, which reverted my Firefox back to v134.0.1. I then reinstalled v134.0.2 … and now the bug is gone. Firefox windows behave normally and retain their custom size when closing/opening them.

I have no idea what made the bug go away, any more than what caused it originally.

Comment 4

[joemcken64]

Update again: … And just now, for no apparent reason, AFTER launching Firefox and everything working normally, it started doing it again. New windows are suddenly ignoring custom sizing, etc.

Comment 5

[Monica Chiorean]

I am not able to reproduce the issue on Win11x64 using firefox builds 135.0 and 136.0a1.
Joemcken64, can you confirm issues is still reproducing with latest 135.0?

Comment 6

[joemcken64]

(In reply to Monica Chiorean from comment #5)

I am not able to reproduce the issue on Win11x64 using firefox builds 135.0 and 136.0a1.
Joemcken64, can you confirm issues is still reproducing with latest 135.0?

I am on Win10 (x64) using Firefox 134.0.2, the latest available through the updater, and it is still occurring for me.
I could test with a beta version of FF, but I’m not sure which version to try or where to get it. (I know of the releases page, but I just see a bunch of 135.0bx versions there.)

Comment 7

[joemcken64]

Also, I should mention that I’ve noticed other weirdness with v134.0.2. I mention this not to bring up multiple different issues, but for the possibility that they might all be related, just in case it helps track down a possible shared underlying cause.

For one thing, the browser’s dark mode preference (Settings → Website appearance) has become buggy. Previously, all sites would load with dark mode enabled when available, but since the update some sites don’t enable it automatically, or else they first load in light mode and then, once they’re almost finished loading, switch to dark mode. This is noticeably different behavior.

In addition, some keyboard functions appear to be affected; on at least one website, the Home and End keys don’t work as expected, only jumping to the start & end of a line rather than the start & end of the text area; they also ignore the Shift key entirely, so that Shift+Home/Shift+End doesn’t select any text. That said, I’ve only noticed this specific issue on one website so far, but as it’s something else that also only started after updating from 134.0.1 to 134.0.2, I thought it was worth mentioning.

Comment 8

[Dão Gottwald [:dao]]

(In reply to joemcken64 from comment #6)

I could test with a beta version of FF, but I’m not sure which version to try or where to get it. (I know of the releases page, but I just see a bunch of 135.0bx versions there.)

The mozregression tool is best suited for finding what change may have caused this, which would help us prioritize this and find the right fix. Would you be able to help us get that information? You can find the tool here: https://mozilla.github.io/mozregression/
Thanks in advance!

Comment 9

[joemcken64]

(In reply to Dão Gottwald [:dao] from comment #8)

The mozregression tool is best suited for finding what change may have caused this, which would help us prioritize this and find the right fix. Would you be able to help us get that information? You can find the tool here: https://mozilla.github.io/mozregression/
Thanks in advance!

I’ve just tried mozregression. Unfortunately, I couldn’t get any useful results from it. Trying it with a new default profile doesn’t reproduce the bug, and when I try with my current profile (updated for v134.0.2), the bug persists for every build it tries, all the way back to v133 (which certainly didn’t have the bug). Unfortunately I don’t have a backed-up copy of my profile from v134.0.1 to try it with.

In addition, launching Firefox in Troubleshoot Mode doesn’t fix the bug, but launching it with a new blank profile (using firefox -p) does. Thus, I now suspect the v134.0.2 update somehow corrupted my profile, causing the odd behavior.

I’m now going to start the (long, tedious, desperately unappealing) process of setting up a new profile and configuring it to match my old one, sans the corruption. I’ll be testing it as I go to see if the issue reappears at any point.

Comment 10

[joemcken64]

UPDATE/RESOLVED: It’s not a browser bug. It’s a single setting in a single browser extension.

Specifically, the Private Internet Access VPN extension has a “Fingerprint protection” that, when enabled, makes several modifications to the browser, including overriding its window size, disabling certain APIs, altering the keyboard mapping, and more.

It appears to make these changes deep within Firefox’s own settings, which is why disabling the extension itself and even switching to Troubleshooting Mode didn’t fix it. This is why I figured it was a browser bug or profile corruption.

The extension has another setting, “Always active settings”, that applies its VPN settings to all windows and tabs even when the VPN is disconnected.

I discovered this by pure chance: I had just disabled “Always active settings” when I connected the VPN on my newly reinstalled profile and instantly all the issues came back. Disconnecting from the VPN, or disabling “Fingerprinting protection”, fixes everything.

So … yeah. This isn’t a bug. Resolving this report as “INVALID”. (I assume that’s the correct thing to do here; I don’t want to waste anyone else’s time.)

Comment 11

[Ray Kraesig [:rkraesig]]

(In reply to joemcken64 from comment #10)

So … yeah. This isn’t a bug. Resolving this report as “INVALID”. (I assume that’s the correct thing to do here; I don’t want to waste anyone else’s time.)

It is, yes. Thanks for the followup and diagnosis!