1994908 - New windows open with a flash of a smaller rectangle in the content area, if the first window is maximized and has a remembered-unmaximized-size that's relatively small

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Create a new directory (e.g. /tmp/foo) that contains just the following file, named xulstore.json (this is a reduced version of what I had in my own xulstore.json file):

{"chrome://browser/content/browser.xhtml":{"main-window":{"sizemode":"maximized","screenX":"0","screenY":"0","width":"500","height":"630"}}}

2. Start Firefox using that directory as your Firefox profile (e.g. firefox -profile /tmp/foo)
3. Open a new window in that Firefox session with Ctrl+N and watch carefully.
4. Repeat step 3 several times.

ACTUAL RESULTS:
When your new window opens, it's maximized (per "sizemode":"maximized" in xulstore.json), BUT the initial paint of the maximized window has a weird rectangle that's roughly the size of the viewport that was specified in xulstore.json` (so in this case, 500px by 630px). This ends up looking like a weird rendering glitch/artifact.

EXPECTED RESULTS:
No such off-color rectangle.

ADDITIONAL RESULTS:

• This reproduces in light mode as well as dark mode.
• This is easy to reproduce without needing to hand-edit xulstore.json; that's just a shortcut. I'll post additional slighlty-longer STR in a later comment that don't require any json-crafting.
• I'm testing using Firefox Nightly 146.0a1 (2025-10-16) (64-bit) on Ubuntu 24.04
• Not sure yet what component this belongs in; starting in Widget for now. I haven't tested any platforms beyond Linux as of yet.

Comment 1

[Daniel Holbert [:dholbert]]

STR that don't require you to mess with profile contents or JSON:

1. Start Firefox with a fresh profile.
2. Shrink your Firefox window to be relatively small.
3. Click the Maximize button on your Firefox window.
4. Open a new window (Ctrl + N) and watch carefully.
5. Repeat step 4.

Actual/expected results are the same as in comment 0.

(Steps 1-3 here are equivalent to steps 1-2 in comment 0).

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast (with light color-scheme)

Here's a screencast starting with a completely fresh profile, using a light OS color-scheme preference. When the bug happens here, there's a smaller white square and a larger light-gray background for the rest of the window.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot showing a moment with the misrendering (with light color-scheme)

Here's a screenshot from t=13s in my just-attached screencast, showing the unwanted rendering. Note that the top-left corner of the viewport is a lighter shade of white from the light-gray in the rest of the window.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screencast (with dark color-scheme)

Here's a screencast of how this looks with a dark color-scheme (where the color-difference is much more pronounced and hence this is much more noticeable/annoying).

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: screenshot showing a moment with the misrendering (with dark color-scheme)

Comment 6

[Stephen A Pohl [:spohl]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

• Not sure yet what component this belongs in; starting in Widget for now. I haven't tested any platforms beyond Linux as of yet.

Since this is only confirmed on Linux for now let's start with Widget:Gtk and expand as appropriate.

Comment 7

[Daniel Holbert [:dholbert]]

Pernosco recording (where I start Firefox, with the first window maximized; then I do Ctrl+N and see this bug in the new window)
https://pernos.co/debug/S9w484xgPxb3iHwhSmGz6Q/index.html

Comment 8

[Daniel Holbert [:dholbert]]

(I have a nagging feeling that there might already be a bug on this too, that I interacted with at some point in the past, when using a device where I had Firefox ~always maximized. Though it's possible the symptoms have evolved a bit.)

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Is that a recent regression? Can you use mozregression to find broken commit?
Thanks.

Comment 10

[Daniel Holbert [:dholbert]]

I think it is, yeah. I'll bisect later today.

Comment 11

[Daniel Holbert [:dholbert]]

Regression pushlog:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=6e8c06620eebb349b6c2d7535a415a808a047abf&tochange=160d4122399e6be7adec23b507ba7c1510f809c7
--> Regression from bug 1993570's "Make painting code not use views directly" patch.

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

• Not sure yet what component this belongs in [...] I haven't tested any platforms beyond Linux as of yet.

I tested on macOS now and confirms it repro's there, too, though I need slightly different steps.

My STR there are:

1. Start with a profile that contains the same xulstore.json file as in comment 0.
2. Open a new window (Cmd+N)
3. Maximize that new window (click green button) to fill the display.
4. Open more new windows by holding Cmd and mashing N.

ACTUAL RESULTS:
The new windows that open in step 4 will suffer from this problem, in a way that's worse than shown on linux - Firefox's own toolbar-UI (hamburger menu, etc) gets squished to fit the small rectangle as well, in the brief mis-rendering.

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug on macOS

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: screenshot of misrendering on macOS, when opening a new supposed-to-be-maximized window

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1993570

:emilio, since you are the author of the regressor, bug 1993570, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 16

[Daniel Holbert [:dholbert]]

I can reproduce on Windows 11 as well (using STR from comment 0), FWIW; so this is not platform-specific.

Comment 17

[Daniel Holbert [:dholbert]]

Triaging as S2 given that this is a fairly-visible cross-platform rendering glitch (and given that it's a new regression not yet shipped to release, rather than a longstanding behavior).

Comment 18

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1994908 - Use nearest pres shell widget in ComputeBackstopColor if there's no frame. r=#layout

The problem is that we're painting an about:blank document which hasn't
been laid out yet (there's no root frame).

In that case, we used to get a widget from the view tree, but now we
don't.

Introduce PresShell::GetNearestWidget(), and use it to get the closest
widget if there's no root frame so that we don't paint an opaque
backdrop incorrectly.

Comment 19

[Emilio Cobos Álvarez [:emilio]]

If you could confirm on macOS that this also fixes the issue there (I don't see why not but...) that'd be great.

Thanks!

Comment 21

[Daniel Holbert [:dholbert]]

Thanks for the fix!

(In reply to Emilio Cobos Álvarez [:emilio] from comment #19)

If you could confirm on macOS that this also fixes the issue there (I don't see why not but...) that'd be great.

Sure, I'll rebuild with the patch on macOS to double-check.

Comment 22

[Daniel Holbert [:dholbert]]

Actually, the macOS bad-rendering shown in comment 14 is partly this, and partly an older regression:
(A) The severe dark-/light-gray differentiation is this bug here.
(B) The fact that we're squashing the hamburger-menu & location bar to fit that squished area is an older regression. [bisecting that now]

I imagine (and will confirm) that your patch fixes (A) but not the older (B) issue there. I'll file a bug for (B) once I've got a range for that.

Comment 23

[Daniel Holbert [:dholbert]]

Filed bug 1995424 on (B) from comment 22.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0295e6c095d8
https://hg.mozilla.org/integration/autoland/rev/26f9db4da1ba
Use nearest pres shell widget in ComputeBackstopColor if there's no frame. r=layout-reviewers,dshin

Comment 25

[Daniel Holbert [:dholbert]]

I built without & with this patch on macOS, and confirmed that the patch fixes (A) from comment 22. With this patch, the brief misrendering goes back to looking as it did before this regressed, i.e. it goes back to looking like the screenshot in bug 1995424 comment 2. Still two different gray colors, but not as severely-different as in comment 14.

Comment 26

[amarc]

https://hg.mozilla.org/mozilla-central/rev/26f9db4da1ba

Comment 27

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox145 to wontfix.

For more information, please visit BugBot documentation.

Comment 28

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox145 to wontfix.

For more information, please visit BugBot documentation.

Comment 29

[Emilio Cobos Álvarez [:emilio]]

Can we back out https://hg-edge.mozilla.org/integration/autoland/rev/160d4122399e6be7adec23b507ba7c1510f809c7 from beta only?

Comment 30

[Sandor Molnar[:smolnar]]

^

Comment 31

[Pascal Chevrel:pascalc]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #29)

Can we back out https://hg-edge.mozilla.org/integration/autoland/rev/160d4122399e6be7adec23b507ba7c1510f809c7 from beta only?

Reverted in https://github.com/mozilla-firefox/firefox/commit/286ce97ccb75d4a9f004e98266324e61e1e0c8a7

I am marking 145 as fixed in this bug by this backout.

Comment 32

[Emilio Cobos Álvarez [:emilio]]

Can QA confirm that 145 is fixed? https://github.com/i3roly/firefox-dynasty/issues/85#issuecomment-3482285472 claims it's not fixed but I can't repro on 145.0b9

Comment 33

[Ina Popescu, Desktop QA]

I’ve reproduced the issue on Firefox 145.0b3 on Windows 10. I verified the fix on Windows 10, Ubuntu 22.04 and macOS 15 using Nightly 146.0a1 and Firefox 145.0b9 following the STR from Comment 0 and Comment 1. The issue no longer occurs on Windows 10 and Ubuntu 22.04, but on macOS, following the STR from Comment 12 (maximizing the window using the green button and then opening new windows with Cmd + N), the flash still appears. Please see the recording for reference.
@Daniel, is the macOS issue related to Comment 22 which will be addressed in a separate bug? I'll update the flags accordingly after this confirmation.

Comment 34

[Daniel Holbert [:dholbert]]

(In reply to Ina Popescu, Desktop QA from comment #33)

but on macOS, following the STR from Comment 12 (maximizing the window using the green button and then opening new windows with Cmd + N), the flash still appears. Please see the recording for reference.
@Daniel, is the macOS issue related to Comment 22 which will be addressed in a separate bug? I'll update the flags accordingly after this confirmation.

Thanks! Yeah, the macOS issue shown in your screencast is covered by bug 1995424. It matches my screenshot / screencast in bug 1995424 comment 1 and bug 1995424 comment 2, and it's not expected to be fixed by the patch that landed here.

(This bug here was responsible for a much-more-severe color-difference as shown in bug 1994908 comment 14; and your screenshot doesn't show that severe difference, which is good news.)

Comment 35

[Ina Popescu, Desktop QA]

(In reply to Daniel Holbert [:dholbert] from comment #34)

(In reply to Ina Popescu, Desktop QA from comment #33)

but on macOS, following the STR from Comment 12 (maximizing the window using the green button and then opening new windows with Cmd + N), the flash still appears. Please see the recording for reference.
@Daniel, is the macOS issue related to Comment 22 which will be addressed in a separate bug? I'll update the flags accordingly after this confirmation.

Thanks! Yeah, the macOS issue shown in your screencast is covered by bug 1995424. It matches my screenshot / screencast in bug 1995424 comment 1 and bug 1995424 comment 2, and it's not expected to be fixed by the patch that landed here.

(This bug here was responsible for a much-more-severe color-difference as shown in bug 1994908 comment 14; and your screenshot doesn't show that severe difference, which is good news.)

Thanks for confirming! Updating the flags accordingly now.