1775066 - Default Window Rounding is currently broken on Linux (Resist Fingerprinting)

Status: UNCONFIRMED

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

Description

[matc]

Steps to reproduce:

Set privacy.resistFingerprinting=true in Firefox 103.0a1 (2022-06-20) on Linux
Start firefox
Close firefox
Start firefox
Close firefox

Actual results:

One window is resized to the available screen dimensions.

Expected results:

Both times the window should have the same rounded dimensions.

Comment 1

[BugBot [:suhaib / :marco]]

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.

Comment 2

[matc]

This appears to be happening since the gtk nsWindow no longer pretends to be resized immediately. (https://hg.mozilla.org/mozilla-central/rev/4102176d73ef57acb388b80ccdd9af0686ec6f2d)

The problem is that AppWindow::ForceRoundedDimensions() issues two resizes, one to avoid being to small to accurately calculate the chrome size and one to the resulting rounded dimensions. Both resizes don't change the dimensions immediately, therefore it's possible for second resize to occur while the window already/still has exactly the same size. AppWindow::SizeShellWithLimit ignores the second resize because it appears unnecessary. nsWindow will eventually complete the first resize and we end up without the rounded window size.

This is only observable with the first browser window. I'm assuming that only the first browser window is already visible at time of window rounding.

Comment 3

[matc]

It looks like only the very first browser window gets resized before AppWindow::ForceRoundedDimensions is called. This means the issue probably unrelated to window visibility. Whether nsWindow resizes immediately depends on whether the window is visible or not. That's why this was my first guess.

We can (or kind of have to for GTK) replace the first resize by bypassing nsWindow::Resize and temporarily changing the size of mDocShell directly, get the content size and set mDocShell back to its original size. And then calculate the chrome size from there. Without the first resize it does no longer matter that AppWindow::SizeShellToWithLimit only resizes if necessary.

I have a patch almost ready that does this. But it looks like it's impossible to write a test case that covers this issue.

Comment 4

[matc]

Attachment: WIP: Bug 1775066 - Adapt AppWindow::ForcedRoundedDimensions to new GTK nsWindow resize behaviour

Resizes with GTK no longer pretend to always happen instantly. To
calculate the chrome size we can no longer rely on resizing the window
to avoid minimum size constraints. Instead we can temporarily change the
root shell dimensions directly and use the resulting content size to
calculate the chrome size.