Scenario

Pinyin buffer visibility in Safari (Chinese IME)

When typing Chinese Pinyin in Safari, the Latin buffer (underlined or styled) may render differently than in Chrome—overlap with table cells, clipping, or missing underline—so users cannot see what they are composing before picking hanzi.

ime

Scenario ID

scenario-ime-pinyin-visible-safari

Edit on GitHub

Details

When typing Chinese Pinyin in Safari, the Latin buffer (underlined or styled) may render differently than in Chrome—overlap with table cells, clipping, or missing underline—so users cannot see what they are composing before picking hanzi.

Problem Overview

This scenario focuses on visual feedback of the composition string, not only candidate window position (see scenario-ime-table-cell-pinyin-safari).

Observed Behavior

Desktop vs iOS Safari: Pinyin line visibility differs.
Interaction with contenteditable styling (background, padding).

Impact

Users commit wrong characters because they cannot read the buffer.

References

WebKit bug tracker: search Pinyin + contenteditable

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-0235-chinese-ime-pinyin-table-ios-safari-en	iOS 16+	Mobile (iPhone/iPad) Any	Safari 16+	Chinese (IME) - iOS Chinese Input	draft

Cases

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

IME composition shows Pinyin in table cells on iOS Safari

OS: iOS 16+ · Device: Mobile (iPhone/iPad) Any · Browser: Safari 16+ · Keyboard: Chinese (IME) - iOS Chinese Input

Open case →

Related Scenarios

Other scenarios that share similar tags or category.

Tags: ime, chinese, pinyin, safari, ios

Chinese Pinyin candidate window in table cells (Safari and cross-browser)

When editing Chinese Pinyin inside a table cell—especially on iOS Safari—the IME candidate window can be clipped, positioned incorrectly, or behave differently than in a plain paragraph. Other browsers (Firefox, Edge, Chrome) also show layout-specific quirks.

3 cases

Tags: ime, chinese, safari

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, safari, ios

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, safari, ios

Missing composition events on iOS (IME)

On some iOS Safari versions and keyboards, compositionstart or compositionupdate may not fire reliably for certain languages, while input events still fire—editors that only reconcile on composition boundaries can desync.

1 case

Tags: ime, chinese, safari

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

Comments & Discussion

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