Open Bug 1951690 Opened 1 year ago Updated 2 months ago

UI giving different window sizes each start/rendering glitching out since Firefox 136.0

Categories

(Core :: Privacy: Anti-Tracking, defect, P3)

Product:
Core
Component:
Privacy: Anti-Tracking
Version:
Firefox 136
Type:
defect

Tracking

()

Status:
REOPENED
Tracking Flags:
Tracking Status
firefox139 --- affected

People

(Reporter: sworddragon2, Assigned: fklc)

References

Details

Attachments

(2 obsolete files)

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

Steps to reproduce:

  1. Set privacy.resistFingerprinting to true.
  2. 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.

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.

Component: Untriaged → Privacy: Anti-Tracking
Product: Firefox → Core

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.

fatih, any idea if there is a recent patch, which might have caused this?

Flags: needinfo?(fkilic)

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?

Flags: needinfo?(fkilic) → needinfo?(sworddragon2)

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.

Huh, now I can't reproduce it with or without privacy.resistFingerprinting.skipEarlyBlankFirstPaint enabled, it always opens with the rounded window size. Interesting.

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.

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.

Assignee: nobody → fkilic
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

(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.

Flags: needinfo?(sworddragon2)

(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.

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.

(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.

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

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.

See Also: → 1954170

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.

With Firefox 137.0 all seems unchanged. I can reproduce all as described here unless I start Firefox via the private browsing shortcut in the start menu. But I think now I see why this shortcut is not affected by this bug: I don't see a skeleton UI here so respectively the window is correctly small and no resizing happens. But this makes me wonder now why my permanent private browsing setup does show the skeleton UI if I start Firefox via the normal shortcut in the start menu but it is skipped if I start Firefox via the private browsing shortcut.

But what I'm also wondering is if the changes from bug #1556016 are now included. If so I would assume they might have changed here something but also this bug might just make it hard to tell if the changes got implemented now or not due to the window always starting maximized regardless. But since the private browsing shortcut in the start menu does open Firefox in a small window it seems none or not all of them made it into Firefox 137 or they are locked behind a preference as I would have expected otherwise at least the private browsing shortcut to open Firefox correctly in an unglitched maximized window.

Unfortunately, I'm not 100% sure. My windows device is really slow, so I try to avoid it. The difference between the shortcuts could be due to these lines here https://searchfox.org/mozilla-central/rev/60acd1356b659b858e5f712cc217768aae17fde1/browser/components/BrowserGlue.sys.mjs#1735-1752. I may investigate it sometime in the future.

might just make it hard to tell if the changes got implemented now or not due to the window always starting maximized

you can test by using hamburger menu > new window, it's only the startup window that is affected

Pushed by fkilic@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/474012e38b60 Variant 2 - Rescale top level window on Windows if RoundWindowSize is active. r=win-reviewers,gstoll

https://hg.mozilla.org/mozilla-central/rev/474012e38b60

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
status-firefox139: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 139 Branch

(In reply to Thorin [:thorin] from comment #19)

you can test by using hamburger menu > new window, it's only the startup window that is affected

It is "New private window" for me, since my setup is in permanent PBM. But I still only get a small window with the Firefox pre-137 dimensions but your comment sounds that I indeed should have gotten a maximized window now at default as I would have expected it (so I assume all the important betterboxing changes actually made it into Firefox 137 including the security fixes from bug #1556016 ).

To sum it up: What I would have expected with Firefox 137 and privacy.resistFingerprinting=true + privacy.resistFingerprinting.letterboxing=true :

  • The window honoring the maximized state now and thus starting here always maximized (outside of this bug reported here)
  • The outside of the letterboxed viewport being colored
  • The letterboxed viewport possibly being realigned
  • The security fixes from the mentionted bug + other small changes

What I see from this:

  • The letterboxed viewport being vertically aligned to the top
  • When I do the test on the linked ticket at https://arkenfox.github.io/TZP/tzp.html I see in the summary the error (among a few others indirectly due to bug #1854851 ) '"size_newwin": " ✗ 1600 x 900"' and respectively in the screen section 'inner 1600 x 900 [✓ RFP] [✗ RFP newwin]'. But it is not clear to me why 1600*900 pixels are an issue here as they seem to be correct to me. But below that I see 'viewport 1583 x 900' so maybe this is the culprit and the security fixes do also not apply for me?

There seems to be some jumanji going on and I'm not sure if and how much is related to the bug in this ticket.

1600 x 900 [✓ RFP] [✗ RFP newwin]

how to read it (all methods must be the same or the health checks fail , e.g. css, matchmedia, window.innner*: I allow for subpixels and css being out of range)

  • 1600 x 900 matches letterboxing steps hence the green [✓ RFP]
  • 1600 x 900 does not match stepped sizes within default RFP new window maximums which are 1400 x 900 (privacy.window.maxInnerWidth, privacy.window.maxInnerHeight) hence the red [✗ RFP newwin]
  • ^ they're two separate health checks

edit

'viewport 1583 x 900'

viewport is the inner window minus any non-overlay scrollbars - so your scrollbar size is 17pixels at that zoom level

(In reply to Thorin [:thorin] from comment #23)

  • 1600 x 900 does not match stepped sizes within default RFP new window maximums which are 1400 x 900 (privacy.window.maxInnerWidth, privacy.window.maxInnerHeight) hence the red [✗ RFP newwin]

I guess this might be just this bug reported here then. And maybe I should also wait until Firefox 139 is being released to avoid this bug conflicting with further tests as I still am confused if the starting window should now be maximized normally or not.

I just noticed that bug #1538130 got closed around a year ago so maximized windows seem to be indeed not honored now. But I have created bug #1957870 for this to take up again on it after all the betterboxing improvements in Firefox 137 and even to go a bit ahead. This should also separate those 2 things and avoid cluttering this ticket here more.

See Also: → 1957870
Regressions: 1958625

Reopening this bug as it caused a regression and we'll back it out :/

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Backout by agoloman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4014e487640e Backed out changeset 474012e38b60 as requested by developer.
Attachment #9471724 - Attachment is obsolete: true
Severity: -- → S3
Priority: -- → P3

There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:fkilic, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Flags: needinfo?(gstoll)
Flags: needinfo?(fkilic)

We backed out this patch. We need to fix it some other way. Maybe we can try "variant 1" patch some time later. It isn't a great fix either though.

Flags: needinfo?(fkilic)
Flags: needinfo?(gstoll)
Attachment #9471743 - Attachment is obsolete: true

A few days ago just out of nowhere the bug here didn't trigger for me again - the second time during all this time. I started Firefox and just got the normal rounded window size. But on further restarts the bug always happened then again.

This makes me wonder if there is actually another bug that just skips the skeleton UI and maybe this is when the bug does not happen for me. I also recall that Firefox started pretty fast in this case so maybe this could be true. But since this case is extremely rare I can't test for it to give a definite answer.

The bug still exists in version 148.0 and I'm wondering how many people are actually experiencing and being able to reproduce it as except once for a report on the LibreWolf bugtracker I have never seen somebody somewhere else complaining about this issue. This also makes me wonder if I will still be able to reproduce it once I migrate to a new Firefox profile. I planned to do this a while ago for a better anti-fingerprinting setup but I'm almost always too busy to do this as I wanted to be even done with this last year.

But recently I also noticed bug #2019141 (and it exists independent of the UI elements being temporary glitched from this report here) and I wonder if it might have something to do with this report here. The magnifying glass in the linked report does also update on some window updates similar how I can unglitch the UI elements from this report here if the Firefox window updates (e.g. from refocusing).

Since I got more time and on my tests the new profile frontend works pretty well I was testing if I can reproduce this issue on a new profile and what changes would be required. Once I maximize the window on a new profile, set privacy.resistFingerprinting to true and restart Firefox the bug already triggers (tested with Firefox 154.0).

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: