user.js: `browser.startup.blankWindow` can block RFP newwin and maximize/restore is confusing
Pref browser.startup.blankWindow
- opens Firefox maximised
- indents tab as if it’s in windowed
- breaks “Restore Down” button
I’m experiencing the first two issue since several Firefox version ago (can’t recall exactly). Firefox 109 breaks the “Restore Down” button with browser.startup.blankWindow
set to False (4507). Mainly reporting this to confirm this is not something only on my end.
🟥 https://github.com/arkenfox/user.js/wiki/5.2-Troubleshooting
- I have read the troubleshooting guide, done the checks and confirmed this is caused by arkenfox
- unchecked issues
maywill be closed as invalid
- unchecked issues
🟪 REQUIRED INFO
-
Browser version & OS: Firefox 109 & Windows 10
-
Steps to Reproduce (STR):
- Create a new profile with the Profile Manager.
- Set the new profile as default profile.
- Open the new profile twice to go through the initiation stuffs.
- Close all Firefox instance.
- Open Firefox, notice the layout and the behaviour of “Restore Down” button.
- Close Firefox, add the default user.js into the new profile.
- Remove 4507 from user.js
- Repeat step 5.
- Repeat Step 1-4, 6.
- Repeat step 5.
-
Expected result: In the end of step 5, 8, and 10, Firefox opens in windowed view with working “Restore Down” button; tab is indented; tab indent is removed upon maximising.
-
Actual result: In the end of step 10, Firefox opens maximised with tabs indented inward; the “Restore Down” button does nothing upon being clicked.
-
Console errors and warnings: Nothing.
-
Anything else you deem worth mentioning: I can only reproduce the problem from “cold start”, hence the complicated STR.
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 23 (15 by maintainers)
Commits related to this issue
- remove browser.startup.blankWindow, #1618 — committed to arkenfox/user.js by Thorin-Oakenpants a year ago
- browser.startup.blankWindow, #1618 — committed to arkenfox/user.js by Thorin-Oakenpants a year ago
The issue happens on default Arkenfox (
browser.startup.blankWindow
set tofalse
), setting the pref totrue
happens to fix the issue. Obviously I’m not sure why would that be the case and I’d assume doing so is less than ideal.https://i.cbc.ca/1.3237852.1442878202!/fileImage/httpImage/image.jpg_gen/derivatives/16x9_780/pizza-rat.jpg
thanks @partingscientist for putting up with me - issue is resolved with no need for an override next release (assuming you run prefsCleaner to reset it to default)
here’s TB, and this is not a cold start, I have already opened and closed it a dozen times to get this gif
it’'s way less noticeable in my stable AF’d FF (and I don’t bother in the other releases or my test suite) - and almost all my FF’s are portables (not in
c:\program files\
) and on a mechanical HDD too 😃. In fact stable seems blazingly fast compared to TB - guess it depends on how long since it was last openI think based on this we could remove the pref: it has nothing to do with privacy - only FPing in that it seems to have edge cases with RFP’s newwin which is not a good thing in the grand scheme of everything. Maybe it’s win10/11 thing - I added STR with pref changes on TB’s issue: I cannot replicate on win7, soon to be retired. Maybe it can also happen on mac or linux. Who knows.
newwin is going to get some attention at TB anyway from ma1, and any improvements eventually upstreamed to FF. Hopefully this will fix everything in the future, but given the pref has nothing to our mission (and could affect FPs which is kinda semi-moot in FF), then it can just go