Repository navigation
Modifier key combinations don't send key up events to framework. #44135
Description
Currently, the macOS shell seems to receive the key-up event for command sequences like "⌘-C" and "Shift-A" without producing a key up event in the framework for the letters, which is problematic on the framework side when someone wants to type, much less re-map it to something else, and it causes the framework to think that the non-modifier keys never went up, so they stick until someone presses the key again (e.g. if I press "⌘-C", the framework thinks that the "C" key is pressed until it gets pressed again).
Activity
gspencergoog commentedon Nov 4, 2019
cc @franciscojma86
gspencergoog commentedon Nov 4, 2019
You'll likely need to apply #44130 before you can see what I mean (until it lands).
shyndman commentedon Nov 5, 2019
This might be worth surfacing again. I'm continuing to run this code with no issues.
#38076 (comment)
shyndman commentedon Nov 5, 2019
The linked code was written to fix this issue precisely, although it might not be the best way to approach the problem since it requires a custom
NSApplication. It looks like by the time the events reach the window they've undergone some interpretation by cocoa (which suppresses the keyUp).Maybe there's a way to hook into the raw event stream through a mechanism other than the NSApplication?
gspencergoog commentedon Nov 8, 2019
Thanks @shyndman, we'll definitely look at that method and evaluate it.
[-]Command key combinations don't send key up events to framework. [/-][+]Modifier key combinations don't send key up events to framework. [/+]Add command key bindings to macOS text editing and fix selection. (#4…
franciscojma86 commentedon Nov 21, 2019
Taking a look at this, it seems to be an OS limitation. It seems to only happen with command. While @shyndman suggestion does work, I worry that it might have an unexpected impact given that we would be overriding NSApplication. Another downside I see of that approach, is that it would have to be overriden from the runner app.
@gspencergoog maybe this is something we can workaround on the framework side, to "free" the pressed key when command is released? FWIW if you release cmd before the key,
keyUpis calledfranciscojma86 commentedon Nov 21, 2019
My suggestion wouldn't actually work. Will keep looking into how we can get the raw event.
shyndman commentedon Nov 21, 2019
I have something to consider.
Both Windows and macOS shortcuts work by evaluating a single keyboard key + a set of zero or more modifiers. The advantage of this approach is that a single keydown event describes whether or not to trigger the shortcut's action — no need to store comprehensive keyboard state.
That said, I appreciate that in the current approach you can ask whether a key is down at any point. Useful. You can do this easily in Windows, too, but not in macOS without using lower-level APIs.
franciscojma86 commentedon Nov 22, 2019
@shyndman the behavior you suggest was implemented recently (using the modifies within the NSEvent of the pressed key) so that's indeed a good observation 😄. However, that doesn't solve the problem at hand since we don't even get the NSEvent from the key being released. I just posted a PR for review, using an approach similar to the one you suggested, but using a listener. Thanks for your suggestion!
shyndman commentedon Nov 22, 2019
🍾
github-actions commentedon Aug 25, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.