UI giving different window sizes each start/rendering glitching out since Firefox 136.0
Categories
(Core :: Privacy: Anti-Tracking, defect)
Tracking
()
People
(Reporter: sworddragon2, Assigned: fkilic)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0
Steps to reproduce:
- Set privacy.resistFingerprinting to true.
- Restart Firefox.
Actual results:
The window either starts in windowed mode as expected with RFP (very rare) or it starts out maximized but the UI has graphical issues (starting tab is indented incorrectly and the maximize button shows Firefox as not being maximized (single square)). The visual glitches immediately vanish once Firefox is minimized or even if another application is in the foreground for a moment.
Expected results:
Firefox should always start in windowed mode and using only a part of the screen.
Comment 1•13 days ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Reporter | ||
Comment 2•13 days ago
|
||
The glitches seem to be not only visual as clicking the single square on the top right when Firefox starts maximized does nothing. Also while my installation has permanent PBM enabled if open the link from the start menu that would normally start a private browsing session all is working fine.
Reporter | ||
Updated•9 days ago
|
Comment 3•5 days ago
|
||
fatih, any idea if there is a recent patch, which might have caused this?
Assignee | ||
Comment 4•5 days ago
|
||
I can think of bug 1775698 and bug 1448423. Sounds more like bug 1448423 issue. Can you try setting privacy.resistFingerprinting.skipEarlyBlankFirstPaint
to false and see if it reproduces?
Assignee | ||
Comment 5•5 days ago
•
|
||
Hmm on windows setting privacy.resistFingerprinting.skipEarlyBlankFirstPaint
to false fixes the issue but the weird thing is, it doesn't happen on mac (with this part removed, otherwise early blank first paint doesn't even work on mac) with or without this pref enabled, not sure about other platforms.
Without the patch in bug 1448423, the window starts as maximized and gets resized to RFP size. Bug 1448423 doesn't address anything about actual resizing though. It just skips blank first paint to hide the maximized window resizing back to RFP size.
Assignee | ||
Comment 6•5 days ago
|
||
Huh, now I can't reproduce it with or without privacy.resistFingerprinting.skipEarlyBlankFirstPaint
enabled, it always opens with the rounded window size. Interesting.
Assignee | ||
Comment 7•5 days ago
•
|
||
Okay I have more findings. On windows, If RFP is on AND firefox does a early blank first paint, firefox doesn't resize, on OSX it does. I can't really tell the reason though..
Edit: if shouldCreateWindow returns false, and browser.startup.blankWindow if not False, then the resize doesn't work. Somehow SetupSkeletonUIPrefs affects this process.
Assignee | ||
Comment 8•4 days ago
|
||
Skip Skeleton UI if we are rounding window sizes. We skip it on other platforms, but on Windows, there's another codepath that reads window size and all the other properties from Windows registry and displays a Skeleton UI.
I'll follow up with another patch that doesn't skip it but scales it after it is created.
Updated•4 days ago
|
Assignee | ||
Comment 9•4 days ago
|
||
Reporter | ||
Comment 10•4 days ago
|
||
(In reply to Fatih Kilic [:fkilic] from comment #4)
Can you try setting
privacy.resistFingerprinting.skipEarlyBlankFirstPaint
to false and see if it reproduces?
The issue does not reproduce then anymore and all stays fine even after some further restarts of Firefox. On changing this setting to true again the issue immediately reproduces on the next and further restarts.
(In reply to Fatih Kilic [:fkilic] from comment #6)
Huh, now I can't reproduce it with or without
privacy.resistFingerprinting.skipEarlyBlankFirstPaint
enabled, it always opens with the rounded window size. Interesting.
I'm not surprised that this happened as the user in the linked LibreWolf ticket also experienced the issue unglitching after fiddling a bit around. Unfortunately when I tried a few things a few days ago (altering windows sizes, enabling/disabling the title bar and vertical tabs, adding/removing elements in the symbol bar) I was not able to unglitch this - it still reliable reproduces here (Windows 10 with a desktop resolution of 1680x1050 in case it is relevant). Also I just remember something important that I haven't even mentioned in the startpost yet: Firefox needs to be maximized in the previous session for the bug to reproduce. If Firefox is being closed while unmaximized it will also start unmaximized as intended - but as soon as Firefox is being maximized and closed again the issue reproduces again.
My hope was also a bit that all the changes from bug #1556016 would fix - or more likely just hide - this issue with Firefox 137. But good to see that we probably get a real fix.
The only weird thing I noticed while fiddling around the last few days was that it seems the initial window size from RFP and the window size when unmaximizing Firefox seems to mismatch a bit. For example this Firefox session was started when the window was maximized due to this bug and if I unmaximize it I will get a size that looks similar to the initial RFP window size but if I close Firefox with that now unmaximized window and start it again I will see a vertical window resize of a few pixels happen on every start.
A workaround for this is just to maximize and unmaximize Firefox again and then close it. So the smaller window size will be saved and thus no resizing happens anymore and further starts.
Reporter | ||
Comment 11•4 days ago
|
||
(In reply to sworddragon2 from comment #10)
A workaround for this is just to maximize and unmaximize Firefox again and then close it. So the smaller window size will be saved and thus no resizing happens anymore and further starts.
*on further starts (I wished I could just edit typos). And of course this issue repeats over and over when repeating this so it is not a one-time thing.
Assignee | ||
Comment 12•3 days ago
|
||
Yeah, I think as described in the librewolf ticket, as long as letterboxing works fine, it shouldn't be a big issue. AFAICT, there's an extra skeleton UI on windows that doesn't exists on other platforms. Whenever that skeleton UI shows up, it doesn't resize. My assumption is we save the last window size to registry and load them and skip resizing.
Reporter | ||
Comment 13•3 days ago
|
||
(In reply to sworddragon2 from comment #0)
The window either starts in windowed mode as expected with RFP (very rare) or it starts out maximized but the UI has graphical issues
Little funfact: I got the correct window size (out of the privacy.resistFingerprinting.skipEarlyBlankFirstPaint test) only once and that on the first day after I got the maximized window size a few times before. I'm not sure why this happened as I'm sure the window was not unmaximized before (as I figured out a bit later that unmaximizing the window before closing Firefox causes this issue not to happen). I thought I might have clicked the wrong shortcut in the start menu (for private browsing mode) but that one opens the about:privatebrowsing page (even with permanent PBM and an empty startpage/tab configured) so I would have noticed this. The only thing I could think of is that I restarted Firefox pretty fast multiple times and maybe this provoked a race condition more. But so I did yesterday and the issue always reproduced reliable.
So yeah, something is a bit janky across users on reproducing this issue.
Assignee | ||
Comment 14•3 days ago
|
||
Can you try setting browser.startup.blankWindow
to false and see if you get the correct dimensions? I think the skeleton ui issue is affecting regardless of last window size
Reporter | ||
Comment 15•3 days ago
|
||
With browser.startup.blankWindow set to false Firefox starts always in windowed mode as intended by RFP. Also there is no size mismatch anymore between the initial RFP window size and when I unmaximize from the maximized state - in both cases I get the slightly smaller and identical window size.
As soon as I set browser.startup.blankWindow to true again Firefox starts maximized again and I can also reproduce the window size mismatch behavior.
Assignee | ||
Comment 16•3 days ago
•
|
||
Interesting. So I guess when PreXULSkeletonUI is consumed, RoundWindowSize RFP target doesn't kick in. The ultimate solution would be finding what causes it and fixing that I guess. I created bug 1954170 for record keeping.
Description
•