Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Martin Fox]

On Mon, 14 Aug 2023 16:28:20 GMT, Martin Fox  wrote:

> A KeyCharacterCombination should match a key if the target character is 
> printed on that key. For example, the user should be able to invoke the 
> `Shortcut+'+' ` combination by holding down the Shortcut key and pressing a 
> key that has '+' printed on it. This should work even if '+' is a shifted 
> symbol but the user doesn't hold down the Shift key. 
> 
> The Mac implements KeyCharacterCombinations by monitoring keystrokes to 
> discover the relationship between keys and characters. Currently the system 
> only records the character the user typed and no other characters on the same 
> key. This means a shortcut targeting a shifted character may not work until 
> the user types that character using Shift so the system learns the 
> relationship.
> 
> This PR keeps the same mechanism in place but always records the shifted and 
> unshifted character for each keystroke.
> 
> For the Mac the KeyboardTest app was modified to remove tests for characters 
> accessed using Option. We don't look for these characters because under the 
> hood just about every key has some symbol assigned to the Option modifier 
> that the user probably isn't even aware of. For these character we fall back 
> to the existing logic; once the user types the character it will start 
> working as a shortcut.

I can reproduce this on 13.6. The `charactersByApplyingModifiers` call is 
modifying the event in some way which is disturbing the IME. This is surprising 
given how that call is documented and that it's been around since 10.15. It 
looks like the fix is to do all this processing after we call `handleEvent:` on 
the NSTextInputContext.

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1826521844

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[yosbits]

On Mon, 14 Aug 2023 16:28:20 GMT, Martin Fox  wrote:

> A KeyCharacterCombination should match a key if the target character is 
> printed on that key. For example, the user should be able to invoke the 
> `Shortcut+'+' ` combination by holding down the Shortcut key and pressing a 
> key that has '+' printed on it. This should work even if '+' is a shifted 
> symbol but the user doesn't hold down the Shift key. 
> 
> The Mac implements KeyCharacterCombinations by monitoring keystrokes to 
> discover the relationship between keys and characters. Currently the system 
> only records the character the user typed and no other characters on the same 
> key. This means a shortcut targeting a shifted character may not work until 
> the user types that character using Shift so the system learns the 
> relationship.
> 
> This PR keeps the same mechanism in place but always records the shifted and 
> unshifted character for each keystroke.
> 
> For the Mac the KeyboardTest app was modified to remove tests for characters 
> accessed using Option. We don't look for these characters because under the 
> hood just about every key has some symbol assigned to the Option modifier 
> that the user probably isn't even aware of. For these character we fall back 
> to the existing logic; once the user types the character it will start 
> working as a shortcut.

The environment where I confirmed the problem is as follows.

* macOS Ventura 13.6 (arm64)
* Xcode 15.0.1

The IME settings are as follows.

* [ ] ABC
* [x] 日本語

This issue causes text input and shortcut operations to be ignored when using 
the IME. Almost all apps are affected.

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1826462489

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Martin Fox]

On Sat, 25 Nov 2023 19:13:42 GMT, yosbits  wrote:

>> A KeyCharacterCombination should match a key if the target character is 
>> printed on that key. For example, the user should be able to invoke the 
>> `Shortcut+'+' ` combination by holding down the Shortcut key and pressing a 
>> key that has '+' printed on it. This should work even if '+' is a shifted 
>> symbol but the user doesn't hold down the Shift key. 
>> 
>> The Mac implements KeyCharacterCombinations by monitoring keystrokes to 
>> discover the relationship between keys and characters. Currently the system 
>> only records the character the user typed and no other characters on the 
>> same key. This means a shortcut targeting a shifted character may not work 
>> until the user types that character using Shift so the system learns the 
>> relationship.
>> 
>> This PR keeps the same mechanism in place but always records the shifted and 
>> unshifted character for each keystroke.
>> 
>> For the Mac the KeyboardTest app was modified to remove tests for characters 
>> accessed using Option. We don't look for these characters because under the 
>> hood just about every key has some symbol assigned to the Option modifier 
>> that the user probably isn't even aware of. For these character we fall back 
>> to the existing logic; once the user types the character it will start 
>> working as a shortcut.
>
> !! **This PR causes block-level problems in Japanese environment.**
> 
> When Japanese IME is turned on,
> key input is ignored when Japanese IME is turned on after merging this PR.
> I verified that the problem does not reproduce by reverting to the code 
> before applying this PR.
> 
> @kevinrushforth @andy-goryachev-oracle

@yososs I can't reproduce this with my test apps or with the MonkeyTester. I 
tried both Kana and Romaji on macOS 14 but didn't try every possible input mode.

- Which version of macOS are you using?
- Which input method and mode are you using?
- What KeyCharacterCombinations does your app use?

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1826415920

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[yosbits]

On Mon, 14 Aug 2023 16:28:20 GMT, Martin Fox  wrote:

> A KeyCharacterCombination should match a key if the target character is 
> printed on that key. For example, the user should be able to invoke the 
> `Shortcut+'+' ` combination by holding down the Shortcut key and pressing a 
> key that has '+' printed on it. This should work even if '+' is a shifted 
> symbol but the user doesn't hold down the Shift key. 
> 
> The Mac implements KeyCharacterCombinations by monitoring keystrokes to 
> discover the relationship between keys and characters. Currently the system 
> only records the character the user typed and no other characters on the same 
> key. This means a shortcut targeting a shifted character may not work until 
> the user types that character using Shift so the system learns the 
> relationship.
> 
> This PR keeps the same mechanism in place but always records the shifted and 
> unshifted character for each keystroke.
> 
> For the Mac the KeyboardTest app was modified to remove tests for characters 
> accessed using Option. We don't look for these characters because under the 
> hood just about every key has some symbol assigned to the Option modifier 
> that the user probably isn't even aware of. For these character we fall back 
> to the existing logic; once the user types the character it will start 
> working as a shortcut.

!! **This PR causes block-level problems in Japanese environment.**

When Japanese IME is turned on,
key input is ignored when Japanese IME is turned on after merging this PR.
We confirmed that the problem is not reproduced by reverting back to the code 
before the correction of this PR.

@kevinrushforth @andy-goryachev-oracle

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1826401412

Re: ESC key binding on the Scene

[Martin Fox]

Thiago,

I’ve tested several modal dialogs on Mac, Windows, and Linux and in all but one 
ESC always dismisses the dialog. The only way for a user to back out an edit is 
to use Undo. The exception was the standard open file dialog on the Mac. In 
that dialog the Search field behaves the way you propose; the first ESC cancels 
editing and the second dismisses the dialog.

So I agree with Andy, you could just install a filter that catches ESC and 
unconditionally dismiss the dialog. That’s how most modal dialogs work.

With that said I think we should implement what you propose; if there’s nothing 
to cancel ESC should be allowed to bubble. Just attaching a formatter to a 
field shouldn’t entirely disable the cancel button. In JavaFX events have to 
bubble all the way up to the scene to ensure the cancel and default buttons 
work correctly (which is an unusual design). This isn’t really an issue with 
the presence of the ESC binding but the way TextFieldBehavior implements 
cancelEdit (TextFieldBehavior:170) which consumes the event even if the text 
doesn’t change.

Martin

> On Nov 21, 2023, at 12:14 PM, Thiago Milczarek Sayão  
> wrote:
> 
> Andy,
> 
> I think you're right about the formatter.
> 
> The idea was to let the key propagate if there's nothing to cancel.
> 
> For example:
> If I want to cancel the edit, one ESC. The second ESC would propagate because 
> there's nothing to cancel.
> 
> Thank you for the reply.
> 
> 
> 
> Em ter., 21 de nov. de 2023 às 14:36, Andy Goryachev 
> mailto:andy.goryac...@oracle.com>> escreveu:
>> Dear Thiago:
>> 
>>  
>> 
>> I don’t think it’s related to undo but to a TextField with a formatter.
>> 
>>  
>> 
>> The question is - do you want to disable the standard behavior (updating the 
>> text using the formatter on ESCAPE) completely?  Or perhaps you do want to 
>> let TextField invoke cancelEdit() (see TextInputControlBehavior:178) and 
>> then close the stage?
>> 
>>  
>> 
>> In the latter case you might consider adding an event filter on the Stage 
>> and calling hide() from there in a Platform.runLater()
>> 
>>  
>> 
>> What do you think?
>> 
>>  
>> 
>> -andy
>> 
>>  
>> 
>>  
>> 
>> From: openjfx-dev > > on behalf of Thiago Milczarek Sayão 
>> mailto:thiago.sa...@gmail.com>>
>> Date: Tuesday, November 21, 2023 at 02:37
>> To: openjfx-dev mailto:openjfx-dev@openjdk.org>>
>> Subject: ESC key binding on the Scene
>> 
>> Hi,
>> 
>>  
>> 
>> I would like to use ESC to close Stages. The problem is that if the focus is 
>> on a TextField, it consumes the event.
>> 
>>  
>> 
>> ESC is the key binding to Undo on the TextField, but it's always consumed, 
>> even if there's nothing to undo.
>> 
>>  
>> 
>> Is this correct? Should it not propagate if there's nothing to undo?
>> 
>>  
>> 
>> -- Thiago.
>>