-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Try fix Korean IME on iOS #17680
base: master
Are you sure you want to change the base?
Try fix Korean IME on iOS #17680
Conversation
Does Avalonia do any internal postprocessing of text entered in a I don't know how to explain this without the said postprocessing, and not sure I can fix the problem without understanding how this behavior is possible. |
Nothing? It's quite embarrassing when a user reports to me that such a basic but crucial component as text input is not working properly... I really want to get this fixed, but at this point I've spent hours of my time debugging the problem both on Android and iOS, so I could use some hints. |
|
"basic" |
Is there someone else on the team besides this person that can help? |
I have already given you plenty of information on the corresponding issue. IMEs communicate with the text view via: https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Base/Input/TextInput/TextInputMethodClient.cs Some IMEs require a special text store. We try to fulfill that requirement but it might not work as expected. First, try to understand how the iOS inputContext is working. Multiple protocols are involved. We might not implement some needed parts correctly. All you can do is to debug the order of events. https://developer.apple.com/documentation/uikit/uitextinputdelegate?language=objc |
So it turns out the issue is very much akin to what's happening on Android. When iOS calls a.mp4 |
You can test this PR using the following package version. |
What does the pull request do?
Tries to fix #16956 on iOS.
What is the current behavior?
What is the updated/expected behavior with this PR?
See #16956
How was the solution implemented (if it's not obvious)?
With
ㅅ
in a text box, when the user typesㅓ
, iOS invokesIUIKeyInput.DeleteBackward
to removeㅅ
, and thenIUIKeyInput.InsertText
with서
. Further typingㄴ
should result in another delete followed by the insertion of선
.However, the second
IUIKeyInput.DeleteBackward
does not currently happen andㄴ
is inserted instead, producing서ㄴ
, probably due to how the previous delete was handled internally (resulting in the wrong return value fromIUITextInput.TextInRange
). With my change it is possible to type 3- and 4-character Korean syllabic blocks, but on only the first syllable. Additionally, manual deletion does not remove the entire syllable but only its last part (선
becomes서
when deleting), which is the norm for Korean.Sadly, further syllables continue to be broken, and manual deletes without calling keydown only select the final character. I'd appreciate any tips, especially describing why and how the double key up/down backspace invocation is required.
Checklist
Breaking changes
Obsoletions / Deprecations