Fix iOS TextField cursor placement on CJK punctuation - #3342
Conversation
| } | ||
|
|
||
| /** | ||
| * CJK scripts and full-width forms use character-level cursor placement on iOS. Applying |
There was a problem hiding this comment.
Comment says about iOS only. Is it applicable for Desktop and Web as well?
cc Alexander Maryanovsky (@m-sasha) , Oleksandr Karpovich (@eymar)
There was a problem hiding this comment.
No, the behavior change is iOS-specific IMO.
requiresCharacterLevelCursorPlacement is defined in skikoMain because
the existing Cupertino cursor adjustment and its tests live there, but
determineCursorDesiredOffset only has iOS production call sites:
- the legacy TextField path through
TextFieldPointerModifier.ios.kt - the state-based TextField path through
TextFieldSelectionState.ios.kt
Desktop, Web, and macOS use defaultTextFieldPointer and do not invoke this
logic, so their cursor behavior is unchanged.
There was a problem hiding this comment.
It's also used in internal fun TextFieldDelegate.Companion.cupertinoSetCursorOffsetFocused which is in skikoMain.
But in the end it's iosMain only.
LGTM from web perspective (not affecting web).
|
Could you please trigger the CI workflows for this PR? Andrei Salavei (@ASalavei) And is there a process for regular external contributors (I’ve previously had |
| textLayoutResult.getLineEnd(lineNumber) | ||
| } | ||
|
|
||
| currentText.requiresCharacterLevelCursorPlacement(offset) -> offset |
There was a problem hiding this comment.
The range inside the requiresCharacterLevelCursorPlacement includes U+3000 IDEOGRAPHIC SPACE (Unicode Zs). The new branch runs before isWhitespaceOrPunctuation, so tapping a fullwidth space now leaves the caret on the space instead of moving to the next word.
I would consider moving this check after the currentText.isWhitespaceOrPunctuation(offset)
There was a problem hiding this comment.
Good catch, thank you. U+3000 is indeed included in that range, and its existing whitespace behavior should be preserved.
Moving the character-level check after isWhitespaceOrPunctuation, however, would also route U+3001 IDEOGRAPHIC COMMA back through the punctuation-scanning branch and reintroduce the original cursor-jump issue.
I’ve therefore updated requiresCharacterLevelCursorPlacement to explicitly exclude Unicode whitespace. This preserves the existing Cupertino behavior for U+3000 while keeping character-level placement for CJK punctuation such as U+3001.
I’ve also added regression tests covering both cases.
I can't see this file Andrei Salavei (@ASalavei) anymore. Could you create a youtrack ticket to track it? |
I re-attached it to the YT ticket. Thank you for the PR! Merging it... |
4 participants
Tapping CJK punctuation in an iOS TextField can move the caret to a later
whitespace instead of keeping it near the tapped character.
For example, tapping
、at offset6in the reproduction attached toCMP-10699 moves the selection to offset
130.determineCursorDesiredOffsettreats punctuation as part of Cupertino'sLatin word-snapping behavior. CJK punctuation therefore enters
findNextNonWhitespaceSymbolsSubsequenceStartOffsetand may scan acrossthe following CJK text until it reaches the next whitespace.
Keep character-level cursor placement for CJK scripts and full-width forms
before applying the existing Latin word adjustment. Both
BasicTextField(TextFieldValue)andBasicTextField(TextFieldState)usethis shared iOS path. Android behavior is unchanged.
Fixes https://youtrack.jetbrains.com/issue/CMP-10699
Testing
emoji, supplementary CJK characters, and invalid offsets.
./gradlew :compose:foundation:foundation:iosSimulatorArm64Testthe selection remains at offset
6instead of jumping to130.Release Notes
Fixes - iOS
CJK punctuation.
Google CLA
Signed the Google Contributor License Agreement.