On Mon, 7 Jul 2025 16:59:13 GMT, Martin Fox <m...@openjdk.org> wrote:
>> The Mac platform code figures out where characters are on the keyboard as >> the user types. The character table is updated on every key press by calling >> a registerKeyEvent: in GlassApplication. This character table is used to >> resolve KeyCharacterCombination accelerators like Cmd + "+". >> >> On a US English layout when the user types Cmd + "+" on the main keyboard >> they're actually typing Cmd + "=". There's special handling in macOS for >> this combination that can cause two NSEvents to be sent and so there's >> special handling in the Glass code so we don't process both events. When >> this special case is invoked registerKeyEvent: isn't being called to update >> the character table. This bug was introduced when code was consolidated in >> PR #1528. >> >> The fix is a simple one-liner. I've added a test for this in the >> KeyboardTest.java program. It's an isolated test because it requires the >> Robot to send events to hold down a modifier while a character key is >> pressed. I also updated some obsolete comments and tweaked it to test all >> KeyCharacterCombinations since they should now work reliably on all >> platforms. > > Martin Fox has updated the pull request incrementally with one additional > commit since the last revision: > > Reverted manual tests, added system test, changed check for fake > performKeyEquivalent event. Heads up, I just submitted a PR (#1848) that fixes this bug in an entirely different way. The fix in this PR is much simpler and safer (I would not be afraid to back port it) and so I think it should go forward even if it turns out to be an interim fix. In any case it might take a while for #1848 to get vetted and there's the non-zero chance it will get rejected. But if anyone reviews both you'll see the same area of code affected in GlassView3D.m (the performKeyEquivalent: handling). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1837#issuecomment-3070558749
