Linux font rendering inconsistencies with contenteditable
OS: Linux 20.04+ · Device: Desktop Any · Browser: Edge 110.0+ · Keyboard: US QWERTY
Open case →Scenario
On Linux, fontconfig, subpixel rendering, and fractional DPI can make caret position, selection highlights, and IME candidate anchoring diverge slightly from macOS/Windows—Edge and Chromium builds may differ from Firefox for the same CSS font stack.
On Linux, fontconfig, subpixel rendering, and fractional DPI can make caret position, selection highlights, and IME candidate anchoring diverge slightly from macOS/Windows—Edge and Chromium builds may differ from Firefox for the same CSS font stack.
Visual view of how this scenario connects to its concrete cases and environments. Nodes can be dragged and clicked.
Each row is a concrete case for this scenario, with a dedicated document and playground.
| Case | OS | Device | Browser | Keyboard | Status |
|---|---|---|---|---|---|
| ce-0220-linux-font-rendering-edge | Linux 20.04+ | Desktop Any | Edge 110.0+ | US QWERTY | draft |
Open a case to see the detailed description and its dedicated playground.
OS: Linux 20.04+ · Device: Desktop Any · Browser: Edge 110.0+ · Keyboard: US QWERTY
Open case →Other scenarios that share similar tags or category.
When editing content inside an element with `position:relative`, the text caret (cursor) is completely invisible. Text can be typed and appears in the editor, but there's no visual feedback of where the insertion point is located.
After pasting content into a contenteditable region, the caret position does not end up at the expected location, sometimes jumping to the beginning of the pasted content or to an unexpected position.
Edge on Linux (Chromium-based) can differ from Windows Edge for clipboard MIME types, file paste, and integration with Wayland clipboard—paste into contenteditable may drop images or format differently.
Firefox may hide or misplace the caret when moving across contenteditable=true/false boundaries—widgets and embeds inside editors are affected.
Firefox may not show a caret in an empty block-level contenteditable container until the user types or a br placeholder exists—layout and min-height interact with focus rings.
Have questions, suggestions, or want to share your experience? Join the discussion below.