Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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 entered a new ticket [JDK-8320773](https://bugs.openjdk.org/browse/JDK-8320773). I will submit a fix today. I can test macOS 12, 13, and 14 on Apple Silicon but can't go as far back as 11. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1828153824
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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. Do we want to revert the fix? In any case, we need a new bug report ticket. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1828051972
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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. In language environments that use IMEs, the side effects of this change will be considered block-level. For the app developer, I hope that by his next OpenJFX release there will be a plan to keep this side effect out of the release's binaries. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1827509894
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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 problem occurs on macOS 12 and 13 which is as far back as I can test. Calling charactersByApplyingModifiers modifiers the NSEvent in some way that causes IMEs to malfunction. I've verified that Chinese - Traditional is also affected. The solution is to use the same Carbon calls that I used in PR #425. I've written the code and will perform some more tests before submitting a PR. I'm not sure if the right approach is to re-open the original bug and rejuvenate this PR or submit a separate bug. The fix for the original bug will need to be re-tested. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1826911494
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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
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
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
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: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
On Thu, 16 Nov 2023 01:19:27 GMT, Martin Fox wrote: > I have no idea where to begin with IME-based languages like Japanese good point. IME is probably out of scope then. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1814711215
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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. Looks good. I tested it only on a US keyboard layout, but Andy has done more extensive testing. - Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1209#pullrequestreview-1734732386
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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 created [JDK-8320216](https://bugs.openjdk.org/browse/JDK-8320216) for adding instructions to the test app. It would be nice to have a non-Latin language in the test so I will look into adding Russian, Arabic, or Hebrew. I have no idea where to begin with IME-based languages like Japanese and am concerned that the resulting tests would be very platform-specific. In any case that would be an entirely different test app. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813575324
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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. Marked as reviewed by angorya (Reviewer). definitely as a follow-up. this PR looks good to me. - PR Review: https://git.openjdk.org/jfx/pull/1209#pullrequestreview-1733269777 PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813512442
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
On Thu, 16 Nov 2023 00:20:16 GMT, Andy Goryachev wrote: > Do you think some other layouts should be added to the keyboard test? > (Suggestion: Arabic, Hebrew, Japanese, French, Russian) > > Another suggestion: maybe add the instructions to the KeyboardTest window? Those both sound like good suggestions. I recommend taking them in a follow-up issue rather than as part of this PR. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813511451
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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. 0 failures with German. Do you think some other layouts should be added to the keyboard test? (Suggestion: Arabic, Hebrew, Japanese, French, Russian) Another suggestion: maybe add the instructions to the KeyboardTest window? - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813506093
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
On Thu, 16 Nov 2023 00:10:24 GMT, Martin Fox wrote: > as long as the test and your selected keyboard match. ah! my fault, did not read the javadoc. let me try again. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813501958
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
On Wed, 15 Nov 2023 23:08:44 GMT, Andy Goryachev wrote: > 1. Using French keyboard on mac (and windows), Ctrl-- is expected to produce > the key code RIGHT_PARENTHESIS, correct? Yes, that key turns into right parenthesis with a French layout. > 2. Using KeyboardTest, I am getting: You should not see any failures as long as the test and your selected keyboard match. It looks like you were running the French, German, and Spanish tests while your keyboard was set to U.S. English. Unfortunately you have to change the keyboard layout manually, there's no API in Java that allows me to do it. That's also why I can't run all the tests in one go. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813497442
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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.
All right, so I see "HI" printed twice on macOS and Windows. I guess we are
good here.
A couple of other observations:
1. Using French keyboard on mac (and windows), Ctrl-- is expected to produce
the key code RIGHT_PARENTHESIS, correct?
KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=CONTROL, control}
KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=RIGHT_PARENTHESIS,
control}
KeyEvent{type=KEY_TYPED, character=<\u1B>, text=, code=UNDEFINED, control} <--
missing on Windows, as expected
KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=RIGHT_PARENTHESIS,
control}
KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=CONTROL}
2. Using KeyboardTest, I am getting:
|Layout|w/o combinations|w/o keypad combinations|with all combinations|
|---|---|---|---|
|US|0|0|0
-
PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813415079
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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. let me test with #1264 integrated. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813121386
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
On Wed, 15 Nov 2023 00:54:26 GMT, Martin Fox wrote:
>> @beldenfox thank you. I still not entirely sure what issue is being tested
>> and how to fix it, between this PR and JBS.
>> For example, when I run the application listed in JBS description with your
>> fix, I get one "HI" - is it expected? (I also get 1 "HI" on Windows)
>>
>> On macOS, new KeyCodeCombination(KeyCode.MINUS, KeyCombination.CONTROL_DOWN)
>> does not equal to new KeyCharacterCombination("-",
>> KeyCombination.CONTROL_DOWN) (same on Windows)
>>
>> Interestingly, Ctrl+- on macOS with the US keyboard produces
>>
>>
>> KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=CONTROL, control}
>> KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=MINUS, control}
>> KeyEvent{type=KEY_TYPED, character=<\u1F>, text=, code=UNDEFINED, control}
>> KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=MINUS, control}
>> KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=CONTROL}
>>
>>
>> but on Windows, we don't get KEY_TYPED event:
>>
>>
>> KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=CONTROL, control,
>> shortcut}
>> KeyEvent{type=KEY_PRESSED, character=<\u00>, text=-, code=MINUS, control,
>> shortcut}
>> KeyEvent{type=KEY_RELEASED, character=<\u00>, text=-, code=MINUS, control,
>> shortcut}
>> KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=CONTROL}
>>
>>
>>
>> is this expected?
>>
>> And yes, it would help if we can extract any other issues into their own
>> tickets (unless they all being fixed by this change).
>>
>> If I may make one suggestion - for the sake of reviewers - to re-phrase the
>> JBS ticket in the format of
>> - steps to reproduce
>> - expected outcome
>> - observed outcome
>>
>> it would help a lot!
>>
>> Thanks!
>
> @andy-goryachev-oracle What keyboard layout do you normally use on Windows?
> And Mac? When talking about the behavior of punctuation this is a crucial bit
> of information.
>
>> but on Windows, we don't get KEY_TYPED event:
>> is this expected?
>
> When you hold down Ctrl and press a key the platform may or may not generate
> a low-ASCII control code. JavaFX has never tried to make the platforms
> consistent here, Glass just passes on whatever the OS generates. In any case
> the TextInputControls treat these TYPED events as nuisances, if you look in
> TextInputControlBehavior.java and read `defaultKeyTyped` you'll see how it
> tries to filter out control codes and anything else that looks like it was
> associated with a shortcut.
> @beldenfox thank you. I still not entirely sure what issue is being tested
> and how to fix it, between this PR and JBS. For example, when I run the
> application listed in JBS description with your fix, I get one "HI" - is it
> expected? (I also get 1 "HI" on Windows)
When you run the application in the JBS description and press Ctrl-'-' on the
main keyboard (not the numeric keypad) you should see "HI" printed twice, once
for the MINUS KeyCode combination and once for the '-' KeyCharacter
combination. I'm not sure why that's not working for you on Windows with a U.S.
layout. With that said, on Windows KeyCharacter combinations for punctuation
can be uncertain unless you're running a build with PR #1264 which was just
integrated.
-
PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1812925964
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
On Wed, 15 Nov 2023 00:54:26 GMT, Martin Fox wrote: > What keyboard layout do you normally use on Windows? US layout on both, at least when the events were captured in the previous comment. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1812868772
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
On Tue, 14 Nov 2023 21:03:59 GMT, Andy Goryachev wrote:
>> @andy-goryachev-oracle You're right, this PR also deals with the problem of
>> the map retaining stale entries when the user switches layout. I added
>> details about this to the JBS ticket. We could treat it as a separate bug if
>> you want, to me it's just the sort of standard housekeeping one does when
>> caching information.
>>
>> I also added a note about the KeyboardTest app. This PR scales back that
>> test a bit but this is the first time we've been able to run the
>> KeyCharacterCombinations on the Mac so that portion is basically a new test.
>>
>> Let me know if you want further information in the JBS ticket.
>
> @beldenfox thank you. I still not entirely sure what issue is being tested
> and how to fix it, between this PR and JBS.
> For example, when I run the application listed in JBS description with your
> fix, I get one "HI" - is it expected? (I also get 1 "HI" on Windows)
>
> On macOS, new KeyCodeCombination(KeyCode.MINUS, KeyCombination.CONTROL_DOWN)
> does not equal to new KeyCharacterCombination("-",
> KeyCombination.CONTROL_DOWN) (same on Windows)
>
> Interestingly, Ctrl+- on macOS with the US keyboard produces
>
>
> KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=CONTROL, control}
> KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=MINUS, control}
> KeyEvent{type=KEY_TYPED, character=<\u1F>, text=, code=UNDEFINED, control}
> KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=MINUS, control}
> KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=CONTROL}
>
>
> but on Windows, we don't get KEY_TYPED event:
>
>
> KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=CONTROL, control,
> shortcut}
> KeyEvent{type=KEY_PRESSED, character=<\u00>, text=-, code=MINUS, control,
> shortcut}
> KeyEvent{type=KEY_RELEASED, character=<\u00>, text=-, code=MINUS, control,
> shortcut}
> KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=CONTROL}
>
>
>
> is this expected?
>
> And yes, it would help if we can extract any other issues into their own
> tickets (unless they all being fixed by this change).
>
> If I may make one suggestion - for the sake of reviewers - to re-phrase the
> JBS ticket in the format of
> - steps to reproduce
> - expected outcome
> - observed outcome
>
> it would help a lot!
>
> Thanks!
@andy-goryachev-oracle What keyboard layout do you normally use on Windows? And
Mac? When talking about the behavior of punctuation this is a crucial bit of
information.
> but on Windows, we don't get KEY_TYPED event:
> is this expected?
When you hold down Ctrl and press a key the platform may or may not generate a
low-ASCII control code. JavaFX has never tried to make the platforms consistent
here, Glass just passes on whatever the OS generates. In any case the
TextInputControls treat these TYPED events as nuisances, if you look in
TextInputControlBehavior.java and read `defaultKeyTyped` you'll see how it
tries to filter out control codes and anything else that looks like it was
associated with a shortcut.
-
PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1811629222
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
On Tue, 14 Nov 2023 20:26:00 GMT, Martin Fox wrote:
>> It looks like the scope of this change went beyond the original problem in
>> JBS.
>> Would it be possible to update the JBS ticket with the information in this
>> PR description?
>
> @andy-goryachev-oracle You're right, this PR also deals with the problem of
> the map retaining stale entries when the user switches layout. I added
> details about this to the JBS ticket. We could treat it as a separate bug if
> you want, to me it's just the sort of standard housekeeping one does when
> caching information.
>
> I also added a note about the KeyboardTest app. This PR scales back that test
> a bit but this is the first time we've been able to run the
> KeyCharacterCombinations on the Mac so that portion is basically a new test.
>
> Let me know if you want further information in the JBS ticket.
@beldenfox thank you. I still not entirely sure what issue is being tested and
how to fix it, between this PR and JBS.
For example, when I run the application listed in JBS description with your
fix, I get one "HI" - is it expected? (I also get 1 "HI" on Windows)
On macOS, new KeyCodeCombination(KeyCode.MINUS, KeyCombination.CONTROL_DOWN)
does not equal to new KeyCharacterCombination("-", KeyCombination.CONTROL_DOWN)
(same on Windows)
Interestingly, Ctrl+- on macOS with the US keyboard produces
KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=CONTROL, control}
KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=MINUS, control}
KeyEvent{type=KEY_TYPED, character=<\u1F>, text=, code=UNDEFINED, control}
KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=MINUS, control}
KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=CONTROL}
but on Windows, we don't get KEY_TYPED event:
-
PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1811296143
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
On Tue, 14 Nov 2023 16:52:16 GMT, Andy Goryachev 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. > > It looks like the scope of this change went beyond the original problem in > JBS. > Would it be possible to update the JBS ticket with the information in this PR > description? @andy-goryachev-oracle You're right, this PR also deals with the problem of the map retaining stale entries when the user switches layout. I added details about this to the JBS ticket. We could treat it as a separate bug if you want, to me it's just the sort of standard housekeeping one does when caching information. I also added a note about the KeyboardTest app. This PR scales back that test a bit but this is the first time we've been able to run the KeyCharacterCombinations on the Mac so that portion is basically a new test. Let me know if you want further information in the JBS ticket. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1811194141
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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. It looks like the scope of this change went beyond the original problem in JBS. Would it be possible to update the JBS ticket with the information in this PR description? - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1810682913
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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. @andy-goryachev-oracle Can you be the primary reviewer on this? - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1810498692
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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 is a customer facing issue (see defold/defold#5850). Like most shortcut-related problems there are duplicates in the Defold issue list because KeyCharacterCombinations are malfunctioning in different ways on different platforms and the behavior varies based on the keyboard layout. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1802287346
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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. Adding a comment to keeper the robot away. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1767332449
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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. Adding a comment to keep the bot away. Still hoping this PR gets some review cycles (it's only a tiny little thin one). - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1726383348
Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically
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. Updated the JBS and PR title and added a new test case. The underlying problem is that KeyCharacterCombinations don't work until the user types the character directly which leads to confusing behavior e.g. Cmd+'+' doesn't work on the main keyboard until the user types '+' but then stops working if they type '+' on the numeric keypad. - PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1688551134
