Repository navigation
Conversation
LongCatIsLooong
left a comment
There was a problem hiding this comment.
Would it be possible to fix this in the macOS text input plugin? If there's a way on macOS to tell that there's an active candidate view (for multistage input or emojis/accents) then we probably don't want the framework to handle the keyevent first?
| // The invoke method will still be called even when consumesKey is false, so if | ||
| // it should do nothing when composing, that is up to the implementer to | ||
| // enforce. | ||
| abstract class _WhenNotComposingTextAction<T extends Intent> extends TextEditingAction<T> { |
There was a problem hiding this comment.
Can this be a mixin and we disable the action when there's an active composing region?
|
Yeah this is probably better there in the engine, the key shouldn't come to the framework at all. I'll look into doing it in the engine and will likely close this PR. |
|
This pull request has been changed to a draft. The currently pending flutter-gold status will not be able to resolve until a new commit is pushed or the change is marked ready for review again. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
(PR triage): @justinmc Do you still have plans for this PR? |
|
See the note I added to #85328 for a test case you may want to verify this with. |
|
I'll close this for now while I decide on the best solution. |
Previously, Flutter was unable to navigate the native composing tooltip when using the arrow keys on desktop:
This PR gets it to work by passing the arrow keys through to the platform when composing.
Fixes #85328