1859350 - White flash when opening about:newtab with dark theme

Status: VERIFIED FIXED

(Firefox :: New Tab Page, defect, P2)

Description

[Kestrel]

Attachment: Video of white flash when loading about:newtab

STR:

1. Enable the Dark theme.
2. Create a new tab (about:newtab).
3. Refresh the page, duplicate the page or open many new tabs (hold Ctrl+T).

White flash before showing about:newtab content.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=80384e2c99e87006a2706b701a3185463685fe76&tochange=93cb4f911941645d91cf11ed1b0062f6e351c7f5

Regressed by Bug 1812135.

Comment 1

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

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

For more information, please visit BugBot documentation.

Comment 2

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

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

Comment 3

[Mark Striemer [:mstriemer]]

Wasn't able to reproduce on macOS but was able to reproduce on my Windows VM. May just be a performance thing

This could be related to loading tokens-brand.css now, but I wasn't able to break at the point where the page was still white. Also could be that the toggles aren't cached the same as the rest of the page.

Comment 4

[Mark Striemer [:mstriemer]]

Can you share a profile of this happening? I have noticed it before but it's way more intermittent for me.

Comment 5

[Kestrel]

You can see this by adding an event listener breakpoint on Script > Script First Statement. The white flash is coming from the activity stream body --newtab-background-color, before lwt-newtab-brighttext or inline colors have been applied to the root.

https://share.firefox.dev/3Ss2KYN

Comment 6

[Masatoshi Kimura [:emk]]

Why --newtab-background-color is not aware of color scheme?

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Mark Striemer [:mstriemer] from comment #4)

Can you share a profile of this happening? I have noticed it before but it's way more intermittent for me.

I have some profiles on bug 1863094 (on Ubuntu 22.04). I just verified that I can reproduce on macOS as well (in Nightly on a 2019 MBP, macOS 14, dark system theme), with the same STR documented in bug 1863094. (I'm just holding Cmd+T for a 1-2 seconds, and then pause, and then repeat.) This reproduces a white flash very quickly, usually by the second or third repeat.

Also worth noting: this still reproduces if I use the cog-icon on the new-tab page to turn off all three sliders. That's kind-of handy, since that makes for less unrelated clutter/content-being-painted, so it's easier to see when a flash happens.

Comment 9

[Daniel Holbert [:dholbert]]

Here's a profile I just captured on macOS: https://share.firefox.dev/3FOlSc3

(This profile was with the "light" macOS-system-theme, and dark web-content preference in Firefox Nightly Preferences, FWIW, just to match the color-scheme setup in my dupe bug 1863094. But that doesn't seem to matter much; I also confirmed I can repro with dark system theme paired with "auto" Firefox theme and "auto" color-scheme preference, which is another way of getting a dark new tab page, and is essentially default settings.)

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Masatoshi Kimura [:emk] from comment #6)

Why --newtab-background-color is not aware of color scheme?

It looks like it's theme-aware, rather than color-scheme aware.

That variable is set in chrome://activity-stream/content/css/activity-stream.css which has platform-specific versions, e.g. here's the linux one with the default and then [lwt-newtab-brighttext] (i.e. dark-mode) color values:
https://searchfox.org/mozilla-central/rev/e94bcd536a2a4caad0597d1b2d624342e6a389c4/browser/components/newtab/css/activity-stream-linux.css#36-37,66-67

:root {
  --newtab-background-color: #F9F9FB;
...
:root[lwt-newtab-brighttext] {
  --newtab-background-color: #2B2A33;

So: to get a dark background, we're dependent on the [lwt-newtab-brighttext] attribute being set on the root, and I guess that happens asynchronously and we can sometimes get a paint before it happens?

Comment 11

[Mike Conley (:mconley) (:⚙️)]

I looked into this with hjones today.

The issue seems to be that LightweightThemeChild uses DOMContentLoaded as its trigger event to grab the theme information from the shared memory in Services.cpmm.sharedData, and then dispatches a DOM Event called "LightweightTheme:Set" with the theme information. The underlying about:newtab page has a script called contentTheme.js that listens for that event and knows how to take the theme information and write it via script to the appropriate CSS variables.

Bug 1812135 changed things by making about:newtab load moz-toggle.mjs, which is an async ESM module. DOMContentLoaded will only fire once all deferred scripts (including moz-toggle.mjs) have loaded: https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event

This means that after the document loads, if we're still in the midst of loading moz-toggle.mjs, we might exceed our frame budget and the page might paint, which is where we get the white flash. Sometimes, however, moz-toggle.mjs loads quickly enough and we end up firing DOMContentLoaded / LightweightTheme:Set before the paint, and then things look right.

This is tricky. What we need to do is find a way of running the LightweightThemeChild.update method when we know that the contentTheme.js script has loaded, but without waiting for any async modules to have loaded.

Alternatively, we need to make it so that DOMContentLoaded is not blocked on async modules - either by loading moz-toggle even more lazily, or by "webpacking" it in activity-stream.bundle.js, as newtab modules often are wont to do.

Comment 12

[Daniel Holbert [:dholbert]]

Alternate approaches:

1. we could "cheat" and start out with some more-likely-to-be-correct prefers-color-scheme-determined defaults that apply before we've established the lightweight theme. (We might get it wrong if the lightweight theme disagrees with the prefers-color-scheme preference, but that should only make us paint the wrong thing for maybe-one-frame as in this bug here, and probably very few users would be affected, rather than all users with dark-color-scheme-preference as it stands now.)

2. Maybe we should just stop caring about LightweightTheme entirely in the new tab page, particularly if we're just using it for a dark-vs-light preference? We already seem to not care about it (and instead respect the user's color-scheme preference) in other some internal pages.[i] It feels like maybe the user's color-scheme preference should be the authoritative factor all of the content that we render in the content area, particularly for content like about:home that is likely to be an "interstitial" just before/after visiting a real-website-that-hopefully-respects-the-users's-color-scheme-preference, to avoid sudden changes where 90% of the screen toggles between dark and light.

[i] I'm testing whether-we-respect-it by choosing "Light" in about:addons|Themes, but choosing "Dark" as my color-scheme preference in Firefox Preferences. Under that setup, here's which of our various Firefox-internal pages are light (matching the lightweight theme) vs. dark (matching my color-scheme preference):

• about:home (new tab page), about:firefoxview, about:firefoxview-next are all light (following the lightweight theme)
• about:blank, about:preferences, about:addons, neterror (e.g. https://expired.badssl.com/ ) are all dark (following the web-content color preference)

Comment 13

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1859350 - Load moz-toggle.mjs asynchronously to avoid blocking DOMContentLoaded. r?thecount!

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Hey dholbert, if you have a second, can you see if this patch fixes the issue for you locally? For me, this makes the flash go away almost entirely.

Comment 15

[Daniel Holbert [:dholbert]]

Yes, this seems to fix the issue for me locally (testing with an --enable-optimize --disable-debug build) Thanks!

The STR I'm using which show a definite behavior-change:
(1) In about:preferences, choose "website appearance:dark"
(2) Hold down Ctrl+T for ~2 seconds.
(3) Watch the rendering carefully as you release Ctrl+T.
(4) Repeat steps 2-3 as-desired.

Without this patch, this reliably gives me a white flash as the final new-tab renders. ("bad")
With this patch, I never see a white flash as the final new-tab renders. ("good")

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/32de54a7b564
Load moz-toggle.mjs asynchronously to avoid blocking DOMContentLoaded. r=thecount

Comment 17

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/32de54a7b564

Comment 18

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/32de54a7b564

Comment 19

[Andrej (:aglavic)]

(In reply to Pulsebot from comment #16)

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/32de54a7b564
Load moz-toggle.mjs asynchronously to avoid blocking DOMContentLoaded.
r=thecount

== Change summary for alert #40318 (as of Tue, 21 Nov 2023 19:23:19 GMT) ==

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
5%	tart	linux1804-64-shippable-qr	e10s fission stylo webrender	3.96 -> 3.76
4%	tart	linux1804-64-shippable-qr	e10s fission stylo webrender	3.96 -> 3.79

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=40318

Comment 20

[Simona Badau, Desktop QA]

Reproduced the initial issue on Nightly 120.0a1 (Build ID: 20231017211935) on macOS 11.7.

Verified as fixed using Firefox 121.0b2 and the latest Nightly 122.0a1 on macOS 11.7, Ubuntu 22.04 x64, and Windows 10 x64.

Comment 21

[Daniel Holbert [:dholbert]]

(adding bug 1886718 as "see also" for discoverability, for a similar-symptom white-flash in Fenix on Android, specifically on the neterror page in that case.)