Defend against Chrome rewriting the DOM, and add the language setting
Groundwork for un-shelving translations. Chrome's translator rewrites the rendered DOM directly, wrapping text nodes in <font> elements React has never heard of, and the next update can then call removeChild against a parent whose children have moved (facebook/react#11538). This is the structural defence against that, plus the setting the served language will read from. The language setting is `uiLanguage`, and it is deliberately not the `locale` field that already exists. That one is a formatting choice -- what calendar, clock and numerals to use -- and folding the two together would silently rewrite everybody's date format the first time they picked a language. German dates with an English interface is a real preference, and so is the reverse. It defaults to English when absent, which covers both a new account and every settings file written before this, and Accept-Language is not consulted: a served locale should be something the reader chose rather than something guessed and then written down as though they had. Only languages with strings shipped are offered, which today means English alone -- a picker entry without a catalogue behind it would leave the page claiming a language it is not in, which stops a reader translating a page they cannot read. `<html lang>` is set where applyTheme is set: at store module load, from the localStorage cache, before createRoot() has rendered anything. Not in an effect -- a lang that is briefly wrong is enough to raise the translate prompt on a page that needed none. There is no server-rendered alternative to reach for here: ihasmail serves a static shell and holds no account state, and the settings file lives in the reader's own JMAP Files, so reading it before the page existed would mean authenticating to Stalwart on every page load. The static lang="en" in index.html covers the first bytes; the store only ever corrects a reader who chose otherwise. Both halves are tested. translate="no" and class="notranslate" go on the narrow boundaries only: rendered email bodies, raw message source, attachment text, the generated and hand-edited Sieve, the brand and the login name. Not on <body> -- someone whose language ihasmail does not speak yet should still be able to translate the parts that are ours. Email bodies turn out to live in a shadow root, so React never reconciles them and they were never a crash risk; the marker there is about not rewriting what a sender actually wrote. Twenty-four fragile interpolation points were found with the TypeScript parser rather than grep, and fifteen refactored. Pluralisation and "count + label" pairs are collapsed into a single expression so the text is a lone child React updates with textContent, rather than a text node with conditional siblings to insert around. One of them -- InviteCard's {method === "REPLY" && organizer ? "" : ""} -- rendered an empty string either way and is simply gone. The boundary is scoped to the main content, so the header, folder tree and any open composer sit outside it and survive independently. It recovers by remounting the subtree, which costs nothing because everything inside re-derives from the stores, and it logs at info rather than error: a reader translating a page is expected and recovered from, and filing it as an error would put an entry in every console-reading reporter for behaviour that worked. It re-raises anything that is not a DOM mutation error, so a real bug still surfaces as one, and it gives up after three attempts rather than looping invisibly. Worth recording: the crash could not be reproduced on React 19.2.8. Wrapping 207-249 React-managed text nodes in <font>, exactly as the translator does, then driving in-place conditional toggles and navigations, left the app intact with the boundary never firing. The original issue is from React 16 and the reconciler has changed a great deal since. So this lands as defence whose premise is weaker than assumed rather than as a fix for something observed here, and the boundary is insurance rather than a load-bearing part. The notranslate markers and the collapsed interpolations stand on their own merits either way.
This commit is contained in:
@@ -4,6 +4,7 @@ import { loadJson, saveJson } from "@/lib/storage";
|
||||
import { queueSettingsPush } from "@/lib/settingsSync";
|
||||
import { setDateTimePrefs, type DateFormat, type TimeFormat } from "@/lib/datetime";
|
||||
import type { SwipeAction } from "@/lib/swipe";
|
||||
import { resolveUiLanguage } from "@/lib/languages";
|
||||
|
||||
/**
|
||||
* "ihasmail" is a dark theme carrying the palette from ihasmail.org. It is a
|
||||
@@ -88,6 +89,22 @@ export interface Settings {
|
||||
weekStart: 0 | 1 | 6;
|
||||
/** "" = follow the mail server's locale, then the browser's. */
|
||||
locale: string;
|
||||
/**
|
||||
* The language the interface is written in, and what `<html lang>` says.
|
||||
*
|
||||
* Separate from `locale` above, which is a *formatting* choice — what
|
||||
* calendar, clock and numerals to use. They are genuinely different
|
||||
* questions: German dates with an English interface is a real preference,
|
||||
* and so is the reverse. Folding them together would silently rewrite
|
||||
* everybody's date format the first time they picked a language.
|
||||
*
|
||||
* Absent means English, for a new account and for every existing one whose
|
||||
* settings file predates this. The browser's `Accept-Language` is
|
||||
* deliberately not consulted as the stored default: a served locale should
|
||||
* be something the reader chose, not something guessed on their behalf and
|
||||
* then written down as though they had.
|
||||
*/
|
||||
uiLanguage: string;
|
||||
dateFormat: DateFormat;
|
||||
timeFormat: TimeFormat;
|
||||
calendarDefaultView: "month" | "week" | "day" | "agenda";
|
||||
@@ -182,6 +199,7 @@ export const DEFAULT_SETTINGS: Settings = {
|
||||
attachmentReminder: true,
|
||||
weekStart: 1,
|
||||
locale: "",
|
||||
uiLanguage: "en",
|
||||
dateFormat: "auto",
|
||||
timeFormat: "auto",
|
||||
calendarDefaultView: "week",
|
||||
@@ -286,6 +304,7 @@ export const useSettings = create<SettingsState>((set, get) => ({
|
||||
set({ settings });
|
||||
applyTheme(settings);
|
||||
applyDateTimePrefs(settings);
|
||||
applyLang(settings);
|
||||
// Dragging a splitter changes a device key on every frame and must not put
|
||||
// a request in the air; anything else is queued and coalesced.
|
||||
if (Object.keys(next).some((k) => !DEVICE_KEYS.has(k as keyof Settings))) {
|
||||
@@ -297,6 +316,7 @@ export const useSettings = create<SettingsState>((set, get) => ({
|
||||
set({ settings: DEFAULT_SETTINGS });
|
||||
applyTheme(DEFAULT_SETTINGS);
|
||||
applyDateTimePrefs(DEFAULT_SETTINGS);
|
||||
applyLang(DEFAULT_SETTINGS);
|
||||
queueSettingsPush(syncedPart(DEFAULT_SETTINGS));
|
||||
},
|
||||
exportJson() {
|
||||
@@ -318,6 +338,7 @@ export const useSettings = create<SettingsState>((set, get) => ({
|
||||
set({ settings });
|
||||
applyTheme(settings);
|
||||
applyDateTimePrefs(settings);
|
||||
applyLang(settings);
|
||||
},
|
||||
}));
|
||||
|
||||
@@ -325,6 +346,31 @@ function applyDateTimePrefs(s: Settings): void {
|
||||
setDateTimePrefs({ locale: s.locale, dateFormat: s.dateFormat, timeFormat: s.timeFormat });
|
||||
}
|
||||
|
||||
/**
|
||||
* Put the served language on `<html lang>`.
|
||||
*
|
||||
* Chrome offers to translate when the language it detects does not match the
|
||||
* one the page declares, so a `lang` that is briefly wrong is enough to raise
|
||||
* the prompt on a page that was already correct — and accepting that prompt is
|
||||
* what rewrites the DOM under React and crashes the component tree
|
||||
* (facebook/react#11538).
|
||||
*
|
||||
* So this is not done in an effect after mount. It runs where `applyTheme`
|
||||
* runs: at module load, from the localStorage cache, before `createRoot()` has
|
||||
* rendered anything and therefore before first paint. `index.html` ships
|
||||
* `lang="en"` statically, so the very first bytes are already right for the
|
||||
* default and this only ever corrects a reader who chose otherwise.
|
||||
*
|
||||
* There is no server-rendered alternative to reach for. ihasmail serves a
|
||||
* static shell and keeps no account state; the settings file lives in the
|
||||
* reader's own JMAP Files on the mail server, so the only way to read it
|
||||
* before the page existed would be to authenticate to Stalwart on every page
|
||||
* load, which is the thing the whole design avoids.
|
||||
*/
|
||||
export function applyLang(s: Settings = useSettings.getState().settings): void {
|
||||
document.documentElement.lang = resolveUiLanguage(s.uiLanguage);
|
||||
}
|
||||
|
||||
/** Background of each theme, for the browser chrome (`theme-color`). */
|
||||
const THEME_COLOR = { light: "#ffffff", dark: "#0b1220", ihasmail: "#0d2430" } as const;
|
||||
|
||||
@@ -360,6 +406,10 @@ export function isDarkTheme(theme: Theme, prefersDark = false): boolean {
|
||||
|
||||
if (typeof window !== "undefined") {
|
||||
applyTheme();
|
||||
// Before `createRoot().render()` in main.tsx, which imports this module on
|
||||
// the way in -- so the language is declared before React has produced a
|
||||
// single node, let alone painted one.
|
||||
applyLang();
|
||||
window.matchMedia?.("(prefers-color-scheme: dark)").addEventListener("change", () => applyTheme());
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user