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

[Andy Goryachev]

On Sat, 27 Jan 2024 19:15:01 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.
>
> I need to amend this PR. If the IM is disabled in the middle of composition we don't dismiss the IM window. In the past that was sort of OK because we ignored the enabled stated and kept sending events to the NSTextInputContext. With this PR we honor the state and stop talking to the context so the IM window just freezes and never goes away. I'll be adding a line of code to ensure we get rid of the IM window when the enabled state changes (which we should have been doing all along).
> 
> This condition can arise if the user starts composing and then clicks on a control that doesn't accept IM input (like a button). It can also happen with [JDK-8087477](https://bugs.openjdk.org/browse/JDK-8087477) which is a bug I'm still investigating.

@beldenfox 
are you going to update this PR with a fix for dismissing the IME window you alluded in the previous comment?

I don't know whether it's the side effect of that scenario, or a new issue, but try this:

- using a simple app with a TextArea with pre-existing text (I am using the MonkeyTester, but any simple app would do)
- switch to japanese/romaji input
- type in "ariga".  you'll see the IME window with some candidates (for some reason, the IME window disappears on "ari" - I guess it's expected since the native TextEdit app exhibits the same behavior)
- click elsewhere.  the IME window disappears
PROBLEM 1: the inline candidate remains underlined
- switch to German input
- click on some other position in the text
- type in + q (from JDK-8088172)
PROBLEM 2: the text gets inserted into a different position, replacing that underlined Japanese candidate created earlier

![Screenshot 2024-01-29 at 10 59 45](https://github.com/openjdk/jfx/assets/107069028/50de825a-c584-4f43-9b64-5b412c1ebe13)

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

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