RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2]

[Andy Goryachev]

On Sat, 27 Jan 2024 19:19:48 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> 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.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   When IM enabled state changes we dismiss the IM window.

> [JDK-8320912](https://bugs.openjdk.org/browse/JDK-8320912). I put together a fix for that bug but decided not to roll it into this PR.

Are these two bugs independent?  Should JDK-8320912 be resolved first?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1917331034