fix(win32): encode KEY_EVENT_RECORD.uChar as UTF-8 for IME input#78
Open
KoalaHao wants to merge 2 commits into
Open
fix(win32): encode KEY_EVENT_RECORD.uChar as UTF-8 for IME input#78KoalaHao wants to merge 2 commits into
KoalaHao wants to merge 2 commits into
Conversation
KEY_EVENT_RECORD.uChar is a single UTF-16 code unit, but the downstream InputParser decodes as UTF-8 (1/2/3/4-byte sequences dispatched by leading byte). The old code returned String.fromCharCode(char).codeUnits, which for e.g. 你 (U+4F60) produced the int 0x4F60 - not a valid UTF-8 byte - so IME characters (Chinese, Japanese, Korean, anything CJK) never reached the text field. Now encoded as proper UTF-8 via utf8.encode(), with a _pendingHighSurrogate field to reassemble supplementary-plane characters (e.g. emoji) across two consecutive key events. Orphans are discarded so a half-pair followed by a different key never produces a wrong character. Verified: 你 (U+4F60) -> 'e4 bd a0', (surrogate pair 0xD83D/0xDE00) -> 'f0 9f 98 80', both round-trip through utf8.decode.
…xtField
The cursor position was displayed wrong when the text had multiple
consecutive newlines (e.g. "hello\n\nworld"). The _paintCursor
method tracked character offsets across layout lines incorrectly.
The old code checked textSoFar.endsWith('\n') — whether the text
*up to* the current offset ends with a newline. But textSoFar only
includes characters before position charCount, so it would never
detect the newline that sits AT position charCount.
Fix: check _text[charCount] == '\n' instead, consistent with the
correct pattern used in CursorMovement.getCursorPosition and
selection_utils.lineStartOffsets.
Bug introduced in a0c5bd4 (Feature/soft wrapping textfield Norbert515#6).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
KEY_EVENT_RECORD.uChar is a single UTF-16 code unit, but the downstream InputParser decodes as UTF-8 (1/2/3/4-byte sequences dispatched by leading byte). The old code returned String.fromCharCode(char).codeUnits, which for e.g. 你 (U+4F60) produced the int 0x4F60 - not a valid UTF-8 byte - so IME characters (Chinese, Japanese, Korean, anything CJK) never reached the text field.
Now encoded as proper UTF-8 via utf8.encode(), with a _pendingHighSurrogate field to reassemble supplementary-plane characters (e.g. emoji) across two consecutive key events. Orphans are discarded so a half-pair followed by a different key never produces a wrong character.
Verified: 你 (U+4F60) -> 'e4 bd a0', (surrogate pair 0xD83D/0xDE00) -> 'f0 9f 98 80', both round-trip through utf8.decode.