On Chromium 152 (Electron 44), a bare EditorView (only EditorView.contentAttributes.of({spellcheck: "true", lang: "en-US"}), no other extensions) is never underlined by the native spellchecker, and the right-click menu offers no misspelled word or suggestions — while an otherwise-identical plain contenteditable (same spellcheck/lang, and a static copy of the same .cm-content > .cm-line markup with the exact attribute set CM applies) is checked. It reproduces at top level — not only nested inside another editor, which is where we first hit it (a cell sub-editor inside a larger CM document).
What I ruled out while isolating it to the live editing runtime: a static clone of CM’s content DOM is checked fine; mimicking CM’s per-keystroke DOM work in a plain contenteditable (replacing the edited text node or the whole line, re-asserting the selection, synchronously or on rAF) does not reproduce it; and replacing a text node/line after typing does not remove an already-painted marker. So it does not look like markers being wiped — the marker is simply never created for the CM host. Chromium 152 also appears to only mark genuinely typed text (attribute toggles / refocus do not trigger a re-check), so once the after-typing marking is missed there is no recovery.
Standalone repro (unmodified @codemirror/view 6.43.1 bundled with esbuild, no application code): Repro: native spellcheck never applied to a CodeMirror 6 editing host on Chromium 152 (Electron 44) · GitHub — open in Electron 44 / Chrome 152 and type “recieve here” in each box: the plain contenteditable box squiggles, both CodeMirror boxes stay clean.
Is there anything in CM’s beforeinput/DOMObserver/selection-write path that could prevent Blink from completing its “mark misspellings after typing” pass for the view’s content element — and any way to nudge that pass to run? Happy to file a Chromium bug as well if this looks Blink-side from where you sit.