Fix iOS TextInput IME composition issues for CJK languages

[kdwkr]

Summary:

CJK (Chinese/Japanese/Korean) IME composition on Fabric is broken — the composition state is destroyed during input, and the composition underline never renders. This affects Japanese, Chinese, and Korean users on the New Architecture.

Root causes and fixes:

1. defaultTextAttributes reapplied during composition destroys marked text — updateEventEmitter:, updateProps:, and traitCollectionDidChange: all set defaultTextAttributes directly, which calls [super setDefaultTextAttributes:] and reapplies attributes to the entire text, interfering with the composition state. Fix: defer during active markedTextRange by storing in _pendingDefaultTextAttributes, apply after composition ends in textInputDidChange. When updateProps defers, it preserves the event emitter key from any prior pending updateEventEmitter update. When traitCollectionDidChange defers, it carries forward the existing event emitter key.

2. _setAttributedString: overwrites text during state round-trips — updateState: round-trips call _setAttributedString: which replaces attributedText, resetting markedTextRange. Fix: skip when markedTextRange is active; text syncs via textInputDidChange → _updateState after composition.

3. maxLength enforcement blocks IME mid-composition — textInputShouldChangeText:inRange: enforces maxLength without checking markedTextRange, truncating intermediate CJK input (e.g., Korean ㅎ→하→한). Fix: defer maxLength during composition, enforce via post-composition truncation in textInputDidChange with grapheme-cluster-safe truncation (using rangeOfComposedCharacterSequenceAtIndex: to avoid splitting emoji and composed characters). Truncation uses _comingFromJS wrapper to prevent recursive textInputDidChange from textInputDidChangeSelection.

4. textInputDidChangeSelection triggers spurious updates in multiline — isEqual: on NSAttributedString fails during composition due to system underline attributes, causing unnecessary textInputDidChange calls. Fix: use .string isEqualToString: for bare text comparison in both textInputDidChangeSelection and _ignoreNextTextInputCall guard. Also skip the early textInputDidChange call from textInputDidChangeSelection during composition (!markedTextRange guard).

5. setTextAndSelection interferes with composition — JS-driven text and selection updates via setTextAndSelection can destroy the composition state. Fix: skip text update, _updateState, AND selection update (setSelectedTextRange:) entirely when markedTextRange is active. JS re-asserts its controlled value after composition ends via the onChange → setTextAndSelection cycle.

6. _updateState Fabric round-trips during composition — _updateState in textInputDidChange pushes state to Fabric during composition, causing round-trips that interfere with UIKit's marked text rendering. Fix: defer _updateState until composition commits (markedTextRange becomes nil).

7. No-op NSShadow and NSBackgroundColor in defaultTextAttributes/typingAttributes prevent IME composition underline rendering — UIKit uses typingAttributes as the base for marked text rendering. When these contain no-op NSShadow (empty shadow with zero offset/blur) or transparent NSBackgroundColor (added by UIKit as defaults and propagated through React Native's attribute flow), UIKit fails to render the composition underline. This is undocumented UIKit behavior. Fix: strip these no-op attributes (along with the React-internal EventEmitter attribute) from typingAttributes/defaultTextAttributes before passing to UIKit, while preserving user-specified shadow/background values. Applied in three locations: RCTUITextView.setDefaultTextAttributes: (multiline), RCTUITextField.setDefaultTextAttributes: (single-line, stripped before [super setDefaultTextAttributes:]), and _updateTypingAttributes (when reading from Fabric-synced attributed text).

Paper (old architecture) is unaffected; these issues are Fabric-only due to synchronous updateEventEmitter:/updateState: calls.

Fixes #48497
Fixes #55257

Changelog:

[IOS] [FIXED] - Fix CJK IME composition state being destroyed and composition underline not rendering in Fabric TextInput

Test Plan:

Native XCTest (22 tests, all passing):

• Full composition lifecycle simulations for Korean (ㅎ→한, 감사), Japanese (romaji→漢, candidate re-selection 橋→箸), Chinese (Pinyin→中, Zhuyin/Bopomofo→中), and mixed Latin+CJK
• Guard verification: _setAttributedString blocked during composition, deferred defaultTextAttributes preserved/applied, maxLength bypassed during composition, multiline bare text comparison, JS-driven update blocked
• Composition underline attribute preservation tests
• typingAttributes stripping: EventEmitter, no-op NSShadow, transparent NSBackgroundColor removed; user-specified shadow/background preserved; font and foreground color preserved

JS tests (18 tests, all passing):

• Controlled/uncontrolled components with CJK composition event patterns
• Korean multi-syllable, Japanese romaji→hiragana/katakana/candidate re-selection, Chinese Pinyin/Wubi/Zhuyin
• Mixed Latin↔CJK switching, continuous sentence composition
• maxLength interaction, multiline composition, value prop updates

Manual verification (iOS Simulator):

• Japanese Romaji: composition underline visible on every composition (single-line and multiline)
• Chinese Pinyin: composition underline visible on candidates
• Korean: composition works correctly (no underline expected — Korean uses inline replacement)
• English: no regression in normal typing
• Controlled TextInput: value prop works correctly during CJK input
• Native UITextField/UITextView comparison: verified that no-op NSShadow + transparent NSBackgroundColor in defaultTextAttributes blocks composition underline rendering (UIKit undocumented behavior)

Test Video

Chinese, Japanese, Korean

ime.testing.video.mp4

English

english.test.mp4

[cipolleschi]

This is a very delicate set of changes. Can you please attach videos of RNTester working fine with english, japanese, korean and chinese characters, please? This will increase our confidence that everything is working correctly.

[kdwkr]

@cipolleschi I have attached a video demonstrating the tests in English, Chinese, Japanese, and Korean. Please review this PR carefully so that the issues with the CJK IME can be resolved as soon as possible.