Platform support

The browsers, versions, devices and runtimes Edytor supports and is tested on, and where mobile keyboards and IME input stand.

Edytor supports the browsers of Baseline 2024 and later, and its test lanes run the current version of each engine. This page lists those lanes, the oldest supported versions, and what is not tested yet: real phones and their keyboards above all.

Browsers

Every behavior test of the editor runs in the three browser engines, through Playwright 1.59 and the browsers it installs:

The collaboration lane also runs real browsers of the three engines against the room in a local Workers runtime, and the editor-input corpus (randomized typing, deleting, pasting and undo, checked against the document model) runs solo in the three engines and collaborative in Chromium.

The desktop lanes are what “supported” means: selection, typing, deletion, paste, drag and drop, block handles, menus, columns and undo behave the same in the three engines, except where a page names an engine difference (native ↑/↓ across columns, for one).

Supported versions

The oldest versions of the Baseline 2024 browsers:

The package ships modern JavaScript and CSS, with no polyfills and no code paths for older engines: it relies on Intl.Segmenter (a grapheme is one character for the arrow keys and Backspace), String.prototype.toWellFormed, a regular expression with lookbehind, Array.prototype.toSorted and toReversed, ResizeObserver, Element.checkVisibility, color-mix(), container queries, unprefixed mask and :has(). An older browser is not supported: it may refuse to load the package or throw at the first edit, and no fix is made for it. Firefox 115 ESR is too old; the 128 ESR and later are supported.

Where the supported engines still differ, the editor keeps one path for each: the caret under the pointer comes from caretPositionFromPoint (Firefox, Chrome 128, Safari 26.2) or caretRangeFromPoint (earlier Chrome and Safari), and a selection inside a shadow root from the shadow root’s own selection (Chromium), getComposedRanges (Safari) or the document’s selection (Firefox). Engine bugs still open in a supported browser stay worked around, such as Safari’s missing pointerdown for the first press after a drag (WebKit bug 202287). The local copy needs IndexedDB, and compressed snapshots need CompressionStream, which every supported browser has.

These are floors, not tested versions: the lanes run the engines in the Browsers table.

Mobile and touch

The mobile lanes run the Chromium engine as a Pixel 5 and the WebKit engine as an iPhone 13: a phone viewport, a touch-capable user agent, and the beforeinput and composition event sequences Android and iOS keyboards send, replayed by the tests. They cover typing, deleting, line breaks, paste and composing words when the keyboard’s events cannot be canceled, the caret after a delete, inline atoms and images next to those edits, undo, and a columns layout stacked on a narrow screen.

The block chrome is tested under a finger too: a phone has no hover, so every block’s handles show; a tap on a grip selects the block and opens the block menu (Move up and Move down move it, one undo step each), a tap on a + opens the insert menu, and a text selection shows the toolbar, whose buttons a tap applies; each fits the phone’s screen.

They are emulation, not phones. Not tested on devices:

• Android keyboards (Gboard, Samsung Keyboard, SwiftKey): word suggestions, autocorrect, swipe typing, voice input and the keyboard’s own cursor control.
• The iOS and iPadOS keyboards: autocorrect, predictive text, dictation and the text selection handles.
• Long-press gestures on block handles, and drag and drop with a finger (the platform’s own drag and drop, which a long press on a grip starts): on a phone, the block menu’s Move up and Move down are the tested way to move a block.

The editor carries two rules for behavior seen on real devices (the caret Android’s keyboard moves back after a delete, and the jump some IMEs make after a commit), and each is tested by replaying its event sequence. Expect rough edges on real phones: report them with the device, the OS, the browser and the keyboard, and the document’s JSON.

IME input

An IME composition (Japanese, Chinese, Korean and other languages typed through an input method) is one session from its start to its commit, written as one undo step; see History.

A real operating-system IME (macOS Kotoeri, Microsoft IME, Pinyin, Korean 2-set, an Android or iOS keyboard) is not driven by any lane; Chromium’s DevTools path is the closest stand-in.

Accessibility

No screen-reader or keyboard-only audit has been made yet. The editor is a contenteditable region with ARIA attributes for the read-only state; menus and handles are keyboard-operable, but their roles and announcements have not been checked with assistive technology.

Runtimes

Other JavaScript runtimes (Deno, Bun, other serverless platforms) can import edytor/crdt/edytor, which has no Svelte and no browser globals in its import graph, but no lane runs them. The room itself needs a Durable Object; for another platform, see Protocol.