Repository navigation
Chinese IME cannot compose in the input box on iOS (renders fine, cannot be typed) #214
Description
Activity
Hey @hello532, would you like to submit a PR for this issue
- 在提交，Mac下有没可以𬇙ide ，看你有另一个项目。zedra非常好用。只是用了语音输入法，中文直接一次过输入。用手打就不行，请等待提交。 Tan Le ***@***.***>于2026年8月24日 周一21:45写道：…*tanlethanh* left a comment (deltaqdev/zedra#214) <#214 (comment)> Hey @hello532 <https://github.com/hello532>, would you like to submit a PR for this issue — Reply to this email directly, view it on GitHub <#214?email_source=notifications&email_token=AOF4R644TZJHY5FOUPGAFW35LRBF5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZZGYYDSNJXHAYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5396095780>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOF4R64M754SJXRTQRUO6C35LRBF5AVCNFSNUABGKJSXA33TNF2G64TZHMYTCMRZGUYTQNBWGY5US43TOVSTWNJSGM2TCNRVGAZTHILWAI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AOF4R66HD45ULV4L4VHIUS35LRBF5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZZGYYDSNJXHAYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AOF4R6ZLIIVRMMQV2RS2S4D5LRBF5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZZGYYDSNJXHAYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>Reacted by Tan Le
Correcting my own report after reading the code: the guess above (that the input surface
never implementedUITextInputmarked text) is wrong. IME input already works on iOS.KeyboardSupporter.buildComposeRowcreates a realUITextField, so UIKit drives
composition inside it natively — Stroke, Pinyin and Handwriting included.The actual defect is reachability. In
ios/Zedra/KeyboardSupporter.swift:- the only entry point to the composer was a left swipe on the accessory bar, with no
button, icon or hint anywhere handlePanopened withguard extended else { return }, so that swipe was inert unless
the two-row keypad was already showingextendeddefaults tofalse
So on a fresh install the bar is compact, the swipe does nothing, and the composer cannot
be reached at all. It presents exactly as "Chinese cannot be typed", which is how I
originally reported it.Workaround on the current build: switch to the extended two-row keypad first, then swipe
left on the bar — the composer appears and Chinese types normally.PR #217 adds a
⌨key to the compact row and removes theextendedguard.One part of #214 is still open: typing straight into the terminal continues to bypass
composition.include/gpui_ios.hexposes only
gpui_ios_handle_text_input(void*, void*), which carries committed text with no
marked-text state in the ABI, so inline composition there needs that boundary and the
GPUI iOS platform layer in thevendor/zedsubmodule extended as well. Happy to file
that separately if useful.- the only entry point to the composer was a left swipe on the accessory bar, with no
Hey @hello532. New ios testflight version is out and includes the fix. Please help me test it, check the link in readme.md
Problem
On iOS, Chinese renders correctly everywhere (agent output, file contents, existing
messages), but Chinese cannot be typed into the prompt / message input box.
Reported with the stroke-based keyboard (笔画, Apple's built-in "Chinese, Simplified —
Stroke"): composition never lands in the field. Latin/English input into the very same
field works normally.
Expected: standard iOS IME behaviour — inline marked (pre-edit) text while composing, a
working candidate bar, and the selected candidate committed into the input.
Impact: a Chinese-speaking user can read everything the agent says but cannot write a
prompt in Chinese, which makes the app effectively read-only for them.
Reproduce
Observed: no inline composition (marked text) appears and nothing is committed to the
input, so no Chinese text can be entered.
Expected: the same composition flow as any native iOS text field.
Environment
zedra 0.4.2(macOS, arm64); iOS app installed from the App StoreEvidence
Offered as a starting point rather than a verified finding: because glyph rendering is
fine and only composition fails, this looks like the text input not honouring the
UITextInputmarked-text contract (setMarkedText:selectedRange:,unmarkText,markedTextRange) that iOS IMEs depend on. If that is the cause, every IME that composesbefore committing would fail the same way (Pinyin, Handwriting, and also Japanese/Korean)
— only Stroke was confirmed here.
A screen recording would show this best, but attachments cannot be sent from the phone,
which is the subject of a separate report filed alongside this one. Happy to provide a
recording through any channel that works.