Scenario

IME composition start delay on Android

On Android Chrome and other WebView-based surfaces, compositionstart and the first compositionupdate can arrive later than on desktop after the user begins typing—especially for Japanese, Chinese, or Korean IMEs. Code that assumes immediate isComposing === true can mis-handle the first few keystrokes.

ime

Scenario ID

scenario-ime-start-delay-android

Edit on GitHub

Details

On Android Chrome and other WebView-based surfaces, compositionstart and the first compositionupdate can arrive later than on desktop after the user begins typing—especially for Japanese, Chinese, or Korean IMEs. Code that assumes immediate isComposing === true can mis-handle the first few keystrokes.

Problem Overview

Mobile keyboards bundle input differently; the pipeline from key events to composition events has higher latency and may interleave with beforeinput/input in orders that differ from desktop.

Observed Behavior

Brief window where Latin or partial input appears before composition state flips.
Duplicate or missing characters if the editor normalizes too early.

Impact

Race conditions in framework-controlled editors; tests that only run on desktop miss the issue.

Browser Comparison

Chrome vs WebView vs Samsung Internet can differ; same codebase in in-app browsers may diverge from Chrome.

Solutions

Gate structural DOM changes on compositionend when possible.
Do not rely solely on keydown keyCode for IME on Android—pair with composition events.
Test on real devices with Gboard + language packs.

References

UI Events — Composition events

Scenario flow

Visual view of how this scenario connects to its concrete cases and environments. Nodes can be dragged and clicked.

Variants

Each row is a concrete case for this scenario, with a dedicated document and playground.

Case	OS	Device	Browser	Keyboard	Status
ce-0241-ime-start-delay-android-ja-en	Android 10-14	Mobile (Samsung Galaxy Tab S9) Any	Chrome for Android 120+	Japanese (IME) - Gboard or Samsung IME	draft

Cases

Open a case to see the detailed description and its dedicated playground.

Selecting all text delays IME start on Android (Japanese)

OS: Android 10-14 · Device: Mobile (Samsung Galaxy Tab S9) Any · Browser: Chrome for Android 120+ · Keyboard: Japanese (IME) - Gboard or Samsung IME

Open case →

Related Scenarios

Other scenarios that share similar tags or category.

Tags: android, ime, composition

getTargetRanges() returns empty array in beforeinput events

The getTargetRanges() method in beforeinput events may return an empty array or undefined in various scenarios, including text prediction, certain IME compositions, or specific browser/device combinations. When getTargetRanges() is unavailable, developers must rely on window.getSelection() as a fallback, but this may be less accurate.

1 case

Tags: android, ime, composition

Duplicate beforeinput or input events during IME composition

Some browsers and keyboards emit duplicate composition-related input or beforeinput events—especially iOS Safari dictation paths and certain Android keyboards—so naive handlers that insert text on every input may double characters or corrupt state.

2 cases

Tags: ime, composition, chrome

Blur and focus during IME composition (CJK and Japanese Safari)

Moving focus away from the editor while composing text (Chinese, Japanese, Korean) can cancel composition, commit partial text, or leave the IME candidate window out of sync. Safari often shows distinct behavior for Japanese; Chrome behavior for Chinese/Korean is covered in related cases.

2 cases

Tags: ime, composition, chrome

keyCode 229 and Enter during IME composition

During IME composition, keydown often reports keyCode 229 (VK_PROCESSKEY on Windows) for many keys, meaning the event is part of an input method sequence. Enter may commit composition, insert a newline, or be swallowed—Chrome vs Firefox vs Japanese layouts differ. Handlers that assume Enter always means insertParagraph break composition incorrectly.

3 cases

Tags: ime, composition, chrome

IME composition when focus moves between elements (Korean and others)

If the user switches focus to another field, button, or nested contenteditable while Korean (or other) IME composition is active, browsers differ on whether composition is committed, cancelled, or leaves orphan state. Chrome, Safari, and Firefox do not agree; mobile adds more variance.

3 cases

Comments & Discussion

Have questions, suggestions, or want to share your experience? Join the discussion below.