Scenario

IME candidate window positioning

The IME candidate list is anchored to the caret rect; viewport scroll, zoom, CSS transforms, and fixed containers can offset it from the user's expectation.

ime
Scenario ID
scenario-ime-ui-positioning

Details

The IME candidate list is anchored to the caret rect; viewport scroll, zoom, CSS transforms, and fixed containers can offset it from the user’s expectation.

References

Scenario flow

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

React Flow mini map

Variants

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

Case OS Device Browser Keyboard Status
ce-0049-ime-candidate-window-position macOS Ubuntu 22.04 Desktop or Laptop Any Chrome 120.0 Japanese IME draft

Cases

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

Related Scenarios

Other scenarios that share similar tags or category.

Tags: ime, candidate

IME candidate list timing and conversion (kanji, hanzi)

Japanese kanji conversion and Chinese character selection depend on the IME candidate window. Delays, wrong ordering, or Safari-specific lag can cause users to commit the wrong character or see candidates that do not match the underlying buffer—especially under load or in complex layouts.

2 cases
Tags: ime, candidate

Number keys for IME candidate selection (Japanese and Chinese)

Many IMEs let users pick candidates with number keys 1–9. In contenteditable, those keys may be consumed by the IME, intercepted by the page for shortcuts, or mis-handled by Safari—causing wrong selection or cancelled composition.

2 cases
Tags: ime, candidate

Japanese IME candidate and conversion on Firefox

Firefox shows different candidate window behavior or conversion latency than Chrome for some Japanese IME backends—handlers tuned on Chromium may mis-handle conversion commits.

1 case
Tags: ime

beforeinput and input events have different inputType values

During IME composition or in certain browser/IME combinations, the beforeinput event may have a different inputType than the corresponding input event. For example, beforeinput may fire with insertCompositionText while input fires with deleteContentBackward. This mismatch can cause handlers to misinterpret the actual DOM change and requires storing beforeinput's targetRanges for use in input event handling.

1 case
Tags: ime

Selection mismatch between beforeinput and input events

The selection (window.getSelection()) in beforeinput events can differ from the selection in corresponding input events. This mismatch can occur during IME composition, text prediction, or when typing adjacent to formatted elements like links. The selection in beforeinput may include adjacent formatted text, while input selection reflects the final cursor position.

1 case

Comments & Discussion

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