In the Mac glass code the presence of "marked" text (which is tracked in the nsAttrBuffer) signals that an IME is active. In this state the current code assumes that when NSTextInputContext handles a `keyDown:` it will either generate a call to `insertText:replacementRange:` or one of the routines that manipulates the marked (composed) text. But this bug shows that sometimes the IME acts on the event without generating any calls back into glass at all.
In this PR the logic is simplified: if the NSTextInputContext handles the `keyDown:` and there's marked (composed) text we don't generate a KeyEvent. Otherwise we do. This PR removes the `shouldProcessKeyEvent` flag since it no longer assumes we can catch callbacks to update it correctly. The existing code also assumes that the composition phase ends when the NSTextInputContext calls `insertText:replacementRange` to commit the text. This is true but if the user tries to use a dead-key sequence to generate a non-existent character (like an accented 'q') the context will call `insertText` twice while handling one key down event. In that case we can't exit the composition mode upon seeing the first `insertText` call since it will cause us to mis-handle the second one. This PR defers exiting composition mode until the end of `keyDown:`. I also updated a few deprecated constants so this file no longer generates compiler warnings. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into macimefixes - Comment tweaks - Merge remote-tracking branch 'upstream/master' into macimefixes - Modified method of determing which keyDowns are sent as KeyEvents. Changes: https://git.openjdk.org/jfx/pull/1351/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1351&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301900 Stats: 45 lines in 2 files changed: 23 ins; 10 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/1351.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1351/head:pull/1351 PR: https://git.openjdk.org/jfx/pull/1351
