The short version
If you type in multiple languages, rely on dead keys or a compose key, or build typing tests/editors, Linux just changed under your fingertips. Browsers on Linux are moving to native Wayland and its modern input‑method protocols (notably text‑input‑v3), while the new EditContext API in Chromium lets custom web editors receive IME text more directly. Together these updates improve IME accuracy and positioning, but they also change event timing and how key remapping works. (reddit.com)
What actually changed under the hood
- Wayland text input protocols: Instead of X11’s global keyboard stream, Wayland sends input to the focused surface and offers dedicated protocols for text input and IMEs: text‑input‑v3 for apps and input‑method‑v2 for IME engines. The v3 spec even calls out implementation details like commit cycles and payload limits (messages are typically capped around 4 KB). Chromium implements text‑input‑v3.1 as of 2026. (wayland.app)
- Browsers going Wayland‑native: Chromium 141 and newer default to the Wayland Ozone backend on many Linux setups, and Chrome 140 introduced auto‑detection that prefers Wayland where appropriate. Practically, this routes typing through Wayland’s text‑input‑v3 path instead of legacy X11. (community.brave.app)
- EditContext arrives in browsers: The EditContext API shipped in Chromium/Edge 121 (January 2024). It lets web apps (think canvases or highly customized editors) receive IME composition, text updates, and caret‑bounds queries directly—without relying on contenteditable. MDN notes it’s experimental and not yet in all browsers. (developer.chrome.com)
Why your IME, dead keys, and compose key feel different
- Toolkit hand‑offs: GTK 4 increasingly leans on Wayland’s text‑input protocol rather than its own fallbacks for compose/dead keys. When the compositor/IME path isn’t fully wired, users may notice compose/dead‑key regressions until IME support is enabled. Recent Debian reports mention compose/dead keys not working on Wayland in certain GTK4 builds—symptoms of this transition. (bugs.debian.org)
- Browser backends matter: Running a Chromium‑based browser on X11 (XWayland) vs. Wayland can flip the input path. Newer Chromium builds default to Wayland, but if yours doesn’t—or if IME doesn’t activate—you may need to toggle the "Preferred Ozone platform" to Wayland and enable the Wayland text‑input‑v3 path. (community.brave.app)
- The IME pipeline on Wayland: Fcitx5 and IBus are the primary frameworks; Fcitx5 documents best‑practice settings for Wayland, GTK, and Qt (e.g., using text‑input‑v3 for GTK apps; ensuring Qt apps use QT_IM_MODULE=fcitx). If your IME works in native GTK apps but not in Chromium/Electron, enabling the browser’s Wayland IME flags often fixes it. (fcitx-im.org)
How this affects typing tests and web editors
- Event timing shifts: On modern Chromium, IME composition produces a stream of beforeinput/input events with inputType values like "insertCompositionText" while compositionstart/update/end bracket the session. Some engines now dispatch an input event just before compositionend, which can reorder handlers in code that assumed the old sequence. If you record keystrokes/WPM, you must respect `event.isComposing` and wait for compositionend to count committed characters. (w3.org)
- Custom editors should adopt EditContext: If your editor draws its own text (canvas/virtualized DOM), EditContext gives you OS‑accurate composition ranges, caret bounds (for candidate windows), and text updates that mirror native fields. MDN emphasizes it’s experimental—feature‑detect and fall back to the traditional contenteditable path. (developer.mozilla.org)
Minimal migration checklist for developers
1) Don’t treat keydown as text. Use `beforeinput`/`input` and the composition events; defer scoring until `compositionend`.
```js
let composing = false;
editable.addEventListener('compositionstart', () => composing = true);
editable.addEventListener('compositionend', () => { composing = false; finalizeRun(); });
editable.addEventListener('beforeinput', e => {
if (e.inputType === 'insertCompositionText' || e.isComposing) {
// update preview only; don’t count yet
return;
}
// handle committed inserts/deletes here
});
```
2) Respect IME selection. Don’t forcibly move the caret while `isComposing` is true; avoid intercepting Enter/Escape during composition.
3) If you render text yourself, try EditContext:
```js
if ('EditContext' in window) {
const ctx = new EditContext();
canvas.editContext = ctx;
ctx.addEventListener('textupdate', e => render(e.text, e.selectionStart, e.selectionEnd));
ctx.addEventListener('characterboundsupdate', e => positionCandidateUI(e.ranges));
}
```
4) Test with multiple IMEs (CJK, Indic) and with dead/compose keys. Validate on GNOME Wayland and Plasma Wayland.
Practical setup guide for typists (Linux desktops)
- Use a native Wayland session on a current desktop (GNOME 45+/Plasma 6+). Major distros now default to Wayland, and most browsers increasingly follow suit. Firefox, for example, defaulted to Wayland on Linux back in version 121, highlighting the broader shift. (en.wikipedia.org)
- Install and configure your IME framework:
- GNOME: IBus is the default; add engines in Settings.
- KDE/Plasma: Fcitx5 integrates well; for best results on Wayland, follow the Fcitx5 Wayland guide (GTK apps via text‑input‑v3; set `QT_IM_MODULE=fcitx` for Qt apps that need it). (fcitx-im.org)
- Make sure your browser really runs on Wayland:
- On newer Chromium/Chrome (v141+), Wayland is typically automatic; verify in `chrome://gpu` or your About dialog.
- If IME/compose misbehaves, launch with Wayland settings: `--ozone-platform=wayland` and, when needed, `--enable-wayland-ime` plus the Wayland text‑input‑v3 toggle in `chrome://flags`. This routes typing through the modern protocol path that IMEs expect. (community.brave.app)
- Enable a compose key (for accents/math/arrows):
- GNOME: Settings → Keyboard → Special Character Entry → Compose Key (or via `gsettings` per GNOME docs). Compose sequences are resolved by xkbcommon using the system’s Compose files; you can customize via `~/.XCompose`. (help.gnome.org)
What to know about remapping on Wayland
Classic X11 tools like `xmodmap` and global key injectors don’t work the same on Wayland due to its security model (no global input snooping/injection). Prefer device‑level remappers such as keyd, input‑remapper, or xremap, which operate via `evdev/uinput` and are Wayland‑friendly. Some features (like per‑app remaps) may require compositor support or helper scripts. (github.com)
- keyd: powerful, low‑level daemon; works under GNOME Wayland and Sway; per‑app mapping may vary by compositor. (github.com)
- input‑remapper: GUI‑friendly; supports keyboards/mice/gamepads across X11 and Wayland via uinput. (github.com)
- xremap: YAML‑based remapper with Wayland support (needs udev rules). (github.com)
For typing‑test owners: a quick QA matrix
- Browsers: Test on Chrome/Chromium/Edge 121+ with EditContext; verify IME candidate window positioning and selection painting. MDN flags the API as experimental—feature‑detect. (developer.mozilla.org)
- Desktops: Validate on GNOME and Plasma Wayland with Fcitx5 and IBus (Korean/Japanese/Chinese; Hindi/Bengali; Arabic/Hebrew). Follow the Fcitx5 Wayland notes for Qt‑based environments. (fcitx-im.org)
- Events: Assert that `beforeinput` with `insertCompositionText` fires during composition and that you don’t double‑count the final `input` before `compositionend`. (w3.org)
The road ahead
Expect incremental polish: Chromium’s text‑input‑v3 implementation (now at v3.1) continues to mature across compositors; toolkits keep handing off more responsibilities to Wayland IME paths; and EditContext is iterating through standards and compat. The bottom line: web typing on Linux is finally aligning with the platform’s native input methods—more accurate, more secure, and more consistent across apps—provided you and your code are ready for the new rules. (fosdem.org)
