2031465 - White flash on startup caused by abouthome_cache storing incompatible startup frame

Status: RESOLVED FIXED

(Firefox :: New Tab Page, defect)

Description

[Andrew]

Steps to reproduce:

1. Install Firefox 149.0.2 on Windows 11
2. Launch Firefox and wait — Remote Settings automatically installs [e-mail] version 151.2.20260328 via rollout "New Tab 151.2.20260328.211913 to Release 149"
3. Restart Firefox

Expected result:
Firefox opens smoothly without visual artifacts

Actual result:
Screen flashes white for ~1 second during startup, before the UI finishes rendering

Additional info:

• Reproduces on any profile, including a brand new clean profile with no account and no customizations
• The rollout is visible in about:support under "Remotely Enabled Features": "New Tab 151.2.20260328.211913 to Release 149 (rollout)"
• [e-mail] version 151.2.20260328.211913 installed via app-profile (not app-builtin)
• Without the rollout the flash does not occur
• Tested on: Firefox 149.0.2, Windows 11 build 26200, NVIDIA GeForce GTX 1070 Ti, driver 32.0.15.8228

Comment 1

[Andrew]

Update after additional testing on Firefox 150.0:

On Firefox 149, the rollout "New Tab 151.2.20260328.211913 to
Release 149" was delivered via Remote Settings after first launch.
On Firefox 150, it is present by default on all clean profiles
without any Remote Settings sync needed.

Root cause chain:

1. Fresh Firefox install - no flash on very first launch
   (abouthome_cache not yet created)
2. After first launch, abouthome_cache stores a startup frame
3. Every subsequent launch shows white flash from this cached frame

Key finding: the bug is fully resolved by setting
browser.startup.homepage.abouthome_cache.enabled to false,
confirming abouthome_cache as the exact delivery mechanism
of the visual artifact.

Note: the rollout "New Tab 151.2.20260328.211913 to Release 149"
was observed on all tested profiles in both Firefox 149 and 150.
Its connection to the bug is unclear but worth investigating.

Comment 2

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:thecount, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Andrew]

Just to clarify: this issue is highly visible and extremely disruptive specifically when using Dark Theme / Dark Mode. The white cached frame acts like a flashbang against the dark UI

Comment 4

[Andrew]

This issue reproduces on every startup and disproportionately affects users running system-wide dark themes. The full-screen white cached frame creates a high-contrast flash that is visually aggressive and impacts accessibility and perceived startup quality

Comment 5

[Andrew]

I found and verified a targeted fix (not the abouthome_cache-disable
workaround).

Root cause: dark theme is applied via the &[lwt-newtab-brighttext]
selector, set by JS after Firefox determines the current theme. The
cached about:home snapshot (abouthome_cache) is a static capture — when
it's first painted on a subsequent startup, that attribute isn't present
yet, so default light-theme CSS renders first (white flash) before JS
catches up.

Fix: added an @media (prefers-color-scheme: dark) block in
_theme.scss that applies the dark variables directly via CSS, based on
the OS color scheme, with no JS/attribute dependency. Even the static
cached frame now renders dark immediately.

Verified locally on latest mozilla-central (built from a clean checkout,
./mach build, fresh profile via --ProfileManager):

• Without the patch: white flash reproduces reliably on repeated startup
  with dark system theme.
• With the patch applied: flash no longer occurs, same profile, same
  repeated-startup test.

browser.startup.homepage.abouthome_cache.enabled was left at its
default (true) throughout — this fixes the actual rendering issue rather
than disabling the cache.

Patch attached.

Comment 6

[Andrew]

(In reply to Andrew from comment #5)
I found and verified a targeted fix (not the abouthome_cache-disable
workaround).

Root cause: dark theme is applied via the &[lwt-newtab-brighttext]
selector, set by JS after Firefox determines the current theme. The
cached about:home snapshot (abouthome_cache) is a static capture — when
it's first painted on a subsequent startup, that attribute isn't present
yet, so default light-theme CSS renders first (white flash) before JS
catches up.

Fix: added an @media (prefers-color-scheme: dark) block in
_theme.scss that applies the dark variables directly via CSS, based on
the OS color scheme, with no JS/attribute dependency. Even the static
cached frame now renders dark immediately.

Verified locally on latest mozilla-central (built from a clean checkout,
./mach build, fresh profile via --ProfileManager):

• Without the patch: white flash reproduces reliably on repeated startup
  with dark system theme.
• With the patch applied: flash no longer occurs, same profile, same
  repeated-startup test.

browser.startup.homepage.abouthome_cache.enabled was left at its
default (true) throughout — this fixes the actual rendering issue rather
than disabling the cache.

Patch attached.

Comment 7

[Andrew]

Attachment: Bug 2031465 - Apply dark theme via prefers-color-scheme before lwt-newtab-brighttext is set r?#home-newtab-reviewers!

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/918560dfc88e
https://hg.mozilla.org/integration/autoland/rev/65aaff2e9ae1
Apply dark theme via prefers-color-scheme before lwt-newtab-brighttext is set r=thecount

Comment 9

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/65aaff2e9ae1