On Sat, 27 Jan 2024 19:15:01 GMT, Martin Fox <m...@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  ------------- PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1915373166
