I will see if I can reproduce. I did notice a little while ago (maybe two or three releases) that I had to add 4507 as true to my nightly (which is not arkenfoxed) as the startup was very distracting, opening top-left and then repositioning - so I suspect this is a FF bug if I can reproduce anything

Simplified STR

• new profile, add user.js with override for 4507 and close restart a couple of times
• ? maximize before closing ?
• now test minimize, restore, maximize

a picture is worth a thousand words - can you provide a screenshot of your entire screen showing the three issues (black out any PII - e.g. including the clock)

opens maximized

So you are closing the browser when it is maximized? Otherwise it should open in it's previous size/positions? Or it may be something to so with tiling - IDK - what is your screen resolution? By that I mean the actual screen res you are using, not it's native one - if you are not sure what I am talking about then go to about:config and change privacy.resistFingerprinting to false and load https://arkenfox.github.io/TZP/tzp.html - what is screen and what is available screen

I can only reproduce the problem from "cold start", hence the complicated STR.

that's because the pref only relates to application start (new session). I'm not sure what happens first (reading user.js or the blank paint, I suspect the blank paint) but it's always best to test these startup prefs with a new session

Remove 4507 from user.js

you would override the pref, not remove it from the user.js, and just do an app close/restart before testing (so the pref change is ready) - your STR is fine, but I just want to make sure that readers know to use overrides and not alter the user.js itself

I did notice a little while ago (maybe two or three releases) that I had to add 4507 as true to my nightly (which is not arkenfoxed) as ...

Anecdotally ... I also added it to Dev and Beta at the time (also not arkenfoxed) and this no longer seems to be an issue (but of course I am now several releases along) - which hopefully means this was fixed (if it was bug)

no replies to my questions ... just so you're aware, I won't be doing anything until I have more information (e.g. an image ofg what I' looking for, e.g. were you closing maximized, e.g. are you tiling by chance - i.e edge snapping by the windows OS). I'm not here to exponentially increase my testing based on numerous parameters - more info means I'm more likely to help

Sorry for my slow response, I happen to have more urgent things that distract me. Thank you for willing to spend some time looking at this, and I'll try to provide more information when requested as quickly as possible, given my personal circumstances.

can you provide a screenshot of your entire screen showing the three issues

With the pref, Firefox will open in my machine like the following.

Commenting the pref, Firefox will open in my machine like the following.

So you are closing the browser when it is maximized?

During my testing, I found that the issue is reproducible regardless of the browser being closed when in windowed mode or when maximised.

Or it may be something to do with tiling?

Assuming tiling means snapping a window to a screen edge/area and allowing it to resize in Windows (i.e. FancyZones in PowerToys for areas), I did not do this.

what is your screen resolution?

Screen resolution: 1536 x 864
Available resolution: 1536 x 824

you would override the pref, not remove it from the user.js

The STR was what I did for convenience, should've commented the pref in overrides in STR. Apologies for that!

I will look at this tomorrow, but some quick notes

Where is this decoration issue? I don;t see any thing in the screenshots. Decorations are the restore/min/max/close buttons.

With the pref, Firefox will open in my machine like the following.

I assume you mean it opens like that before resizing automatically because you have RFP enabled?

Screen resolution: 1536 x 864 / Available resolution: 1536 x 824

So you didn't flip RFP. Anyway, from the screenshot, your res is 1920 x 1080. That's what your image toll caught, but each tool can vary - some capture native res, some capture what is actually used. Are you using any system scaling - e.g. 1536 is 1920 at 1.25 system scaling

Commenting the pref, Firefox will open in my machine like the following

your inner window seems to be 1748 x 875px tall, which if I mutiply by 0.8 (the inverse of 1.25 : assuming system scaling) is 1400 x 1228 - the height is weird and very off but the width is spot on.

I can't debug anything here right now

• are you using RFP?
• are you using system scaling?
• if you have RFP enabled, then why are you enabling the pref. What is the need for a split second earlier skeleton painting (you windows caches the program - I use portable and except for the first cold start after a system reboot where it might take 3 seconds to open, it's lightening fast (like 0.2 of a second)

Hopefully I did not misread something.

Where is this decoration issue?

With default arkenfox, pref 4507 causes Firefox on my machine to open up and stay maximised (Pict 1), but the "Restore Down" button is replaced with the "Maximise" button and the tab row is shifted inwards, as if I'm opening Firefox in "windowed" view (Pict 2). The "Maximise" button does nothing when being clicked.

I assume you mean it opens like that before resizing automatically because you have RFP enabled?

It did not resize itself with RFP enabled. It stays like that.

So you didn't flip RFP.

It's the screen res and available screen with RFP off, per your request

      go to about:config and change privacy.resistFingerprinting to false and load https://arkenfox.github.io/TZP/tzp.html -
      what is screen and what is available screen

Are you using any system scaling?

Yes, 1.25.

I'm not quite sure what do you mean about the last part.

per your request

👍 cool, I was just checking because the images resolutions are 1920x1080 - but as I guessed, you are at 1.25 system scaling

but the "Restore Down" button is replaced with the "Maximise" button

oh. I never use those decorations. Now I see .. the middle one - that indicates that either a) the window is not maximized, it is just sized to fit the screen (like tiling) and/or b) since it doesn't seem to then resize as per RFP the decoration is not corrected if wrong

There's a bit going on here. Let's just do this in pieces.

Do a second image test and throw me a screenshot of TZP. I want to make sure that the newwin sizes are correct

Here you go!

👍 cool, I must have confused myself with the width vs your system scaling

So the next step (should have been the first step) is to see if it is still an issue. No point wasting time if it's been fixed. Download and install Nightly (it does not interfere with stable release. If it's still an issue then we can dig further

I can reproduce the issue with Nightly on my machine. Overriding browser.startup.blankWindow (4507) also resolves the issue, consistent with Release.

thanks .. I'll investigate

but again, I have to ask, why override the pref?

The issue happens on default Arkenfox (browser.startup.blankWindow set to false), setting the pref to true 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.

crap, I read the whole issue as being the opposite - that overriding the pref caused the issue. my bad

yes, this is less than ideal. IDK if it's worthwhile to try and diagnose, except that it may would affect newwin sizes for Tor Browser (which we could fix by locking the pref) - the last thing we want is for the newwin size protection to not fire and lave the user left as per your first image (using all the available screen). So I would like to work out why. Part of the problem is trying to replicate it :-( For Firefox users it doesn't really matter than much

So we could probably just drop the pref from arkenfox (or comment it out). I'll test for a while - personally I get annoyed by the resizing steps (and the useless (pale) skeleton (I use dark theming/landing page etc) - which is only there to improve the perception of speed for users) - I am currently on a 11yr+ machine (new one coming shortly), so probably less noticeable for most users

• PS: not talking about first app start on a OS boot (where app is not cached or whatever)

https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41592

I think I nailed the cause in the tor issue - our maximum sizes 1600 x 900 are both larger than your available res 1536 x 824 and the first step is to try the maximum size - the app or OS then automagically resizes it to fit (not the same as maximized, which is why your decorations look wrong). You can achieve the same result with window.resizeTo() in a privileged browser console - i.e you can move and resize the window to exactly fit your screen and it is not "maximized".

As for why newwin (and the code is old, FF55 I think) then doesn't fire is no doubt due to the engineering paths and order or events - edit: and the blankWindow pref changes came in FF60, after RFP's newwin.

which is only there to improve the perception of speed for users

not sure if it's self-suggestion but I can tell the difference

of course you can tell the difference - that's what it's meant to do - look up the word PERCEPTION, I dare you

in reality, it does not speed anything up in terms of the browser being ready for use - it is simply drawing the browser skeleton as soon as it can and then loading the rest

FWIW, I too can tell on the difference (I flipped mine in my AF'ed stable to see if I can live with it): on a not-a-cold-OS/app start, I see my window painted with a pale white inner for a split second before it gets colored in (with my dark speed dial inner newtab/home) etc. Times will vary per user based on the state of the OS, CPU/GPU grunt, caching etc

I don't get repositioning or resizing because I have oodles of real estate and I always close and open my browser in the exact same position/size (1600 x900 at x/y coordinates) - so the only thing that slightly urks me is the non-colored in skeleton (which is not a privacy issue)

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 open

I 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

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)

mechanical HDD

win7

🦕

I'll take a look at the TB issue, thx :-)

🦕

you know I can flex some more on you bro - the new high end laptop, the mac, the coming new high end desktop .. about time, so glad I won the lottery

so glad I won the lottery

jeez.. then have some pizza delivered at my doorstep at least

https://i.cbc.ca/1.3237852.1442878202!/fileImage/httpImage/image.jpg_gen/derivatives/16x9_780/pizza-rat.jpg