Read the settings before the first render, so a custom theme is painted from the app's first render - #651

Why

The follow-up recorded in #650: a custom theme was painted after a first render in the standard theme of its scheme, a flash of the wrong colours at every launch, because the settings, of which the theme is one, were read in an effect once the app had mounted. Part of #560.

What changes

The settings are read before the first render, beside the locale, which the window already waited for; the two reads run together, so the first paint waits for neither longer than before. What was read is handed to the hook that holds the settings, which asks main again only where that read failed, as it did before. No new bridge surface: the same ask, made earlier.

What remains: before the page's script runs at all, the page paints the stylesheet's light surface, or under the dark scheme the dark seed index.html paints, over a window frame that is already the custom colour; a custom theme shows that for that moment, then its own colours. The review's idea of a transparent body until the provider mounts, so the frame shows through, was tried and measured: in the light scheme the window's colour did show through, but under the dark scheme Chromium paints its own canvas colour, #121212, over the frame, so a custom dark theme would still flash, and the standard dark theme would flash a grey that is not its seed. Not taken. The page cannot know its colour before its script runs without being handed it, which is new bridge surface.

Mail rendering is unchanged here and tracked separately.

How to test this

Platforms: any. The journeys drive this on macOS and Windows. From the repository root, after npm ci and npm run build:once:

npx playwright test --project=journeys settings.spec

• settings.spec.js, the custom theme journey, at its end: the page is reloaded with a script in it before any of its own, which notes the document's own style at the moment the app mounts, before anything is painted; the custom colours are in it, and not the standard theme's, and not none. On the code before this change the journey receives an empty style there, since a custom light theme's first render was the standard light theme, which puts nothing on the document.

Nothing else is new to test: the settings dialog's journeys and the language relaunch cover the hook as it is handed the settings.

Worth a look by hand (any platform, the current head): Settings → General → Theme → Custom, a background such as fff8e1, quit, open the app: the window is cream from the app's first render, with no moment of the standard light theme after the page has mounted. With 102030: navy from the app's first render; what the page paints before its script runs is the dark seed.

What must not have happened: the app failing to open its window when the settings cannot be read (the read's failure is logged and the hook asks again); a slower first paint; the language relaunch offer appearing on a fresh launch.

What I could not test: the packaged smoke on this head, since my own copy of the app held the single-instance lock; the change is the renderer's and the bridge is unchanged.

Risks and limitations

• Review: 2 passes, 1 finding fixed here, the follow-up tried and not taken, every style note applied. Details below.
• A custom dark theme still shows the dark seed for the moment before the page's script runs. See above.

Related

Follow-up of #650, part of #560 and #542.

🤖 Generated with Claude Code