On Fri, 26 Jan 2024 17:32:02 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. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1913299911
