You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This needs an audit to establish the current state. There's at least IME(Input Method Editor) position error google/flutter-desktop-embedding#345 (I'm not sure if just doing the accessibility API work will resolve that, or we'll need additional work), and we should see if we should be doing any text marking for in-progress compositions (which I know we're currently never sending).
As of flutter-team-archive/engine#24533, the composing region is displayed while typing, but the candidates menu is still not positioned and candidate selection is not implemented. Working on candidate menu positioning next. Once that's done, candidate selection.
@cbracken, I've referenced two PRs that position the candidates menu. I'm not sure what to do about candidate selection through. That is generally implemented by sending arrow key events to [textInputContext handleEvent:]. However right now flutter handles all arrow events. I think ideally all keyboard events should be passed to the TextInputPlugin and caret movement / selection should be driven through NSStandardKeyBindingResponding methods. That way the experience should be as close to native as possible.
caret movement / selection should be driven through NSStandardKeyBindingResponding methods.
The issue currently is that the framework also does all of that, and if the framework and the engine get out of alignment they fight each other. @gspencergoog and I have talked about changing the source of truth on some of this, but deciding exactly what goes where is something that should be carefully thought (and design-doc'd) out across all platforms rather than continuing to tweaked per platform, IMO.
@knopp The keyboard events need to pass through the framework before being sent to the TextInputPlugin so that the framework has a chance to override them. As one example, the TAB key needs to be interpreted as a focus change, and it can't do that if the text field inserts TAB. I agree that caret movement should be driven through the NSStandardKeyBindingResponding methods, however. I realize that those two statements are at odds with each other, which is why we need to do some design work around this, as Stuart said. It may be that we need another way to represent caret movement, or that on macOS/iOS that there shouldn't be any default bindings on the framework side for caret movement. The developer should still be able to override those key events, however, and even prevent caret movement by overriding those keys if they want to.
One thing to consider here is that framework may not be able to determine whether arrow key moves caret or selection in candidates menu, so TextInputContext as source of truth might not be optional.
@gspencergoog, I agree completely that framework should have first go at the keyboard event and then pass it on. I do realize that this requires a lot more thinking upfront so I wasn't even trying to implement it :) The positioning of menu on the other hand is lot more straightforward.
Also, regarding the input being stuck in compositing mode, I have this: flutter-team-archive/engine#24866 . Not sure if there is any better way to fix it, there doesn't seem to be any specific notification from system to end compositing.
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 -v and a minimal reproduction of the issue.
Activity
stuartmorgan-g commentedon Sep 10, 2020
This needs an audit to establish the current state. There's at least IME(Input Method Editor) position error google/flutter-desktop-embedding#345 (I'm not sure if just doing the accessibility API work will resolve that, or we'll need additional work), and we should see if we should be doing any text marking for in-progress compositions (which I know we're currently never sending).
GreenLim commentedon Dec 4, 2020
Is there any progress? If you use CJK input method, you will always get a wrong word candidate window position.
cbracken commentedon Mar 5, 2021
As of flutter-team-archive/engine#24533, the composing region is displayed while typing, but the candidates menu is still not positioned and candidate selection is not implemented. Working on candidate menu positioning next. Once that's done, candidate selection.
knopp commentedon Mar 8, 2021
@cbracken, I've referenced two PRs that position the candidates menu. I'm not sure what to do about candidate selection through. That is generally implemented by sending arrow key events to
[textInputContext handleEvent:]. However right now flutter handles all arrow events. I think ideally all keyboard events should be passed to the TextInputPlugin and caret movement / selection should be driven throughNSStandardKeyBindingRespondingmethods. That way the experience should be as close to native as possible.stuartmorgan-g commentedon Mar 8, 2021
The issue currently is that the framework also does all of that, and if the framework and the engine get out of alignment they fight each other. @gspencergoog and I have talked about changing the source of truth on some of this, but deciding exactly what goes where is something that should be carefully thought (and design-doc'd) out across all platforms rather than continuing to tweaked per platform, IMO.
gspencergoog commentedon Mar 8, 2021
@knopp The keyboard events need to pass through the framework before being sent to the
TextInputPluginso that the framework has a chance to override them. As one example, the TAB key needs to be interpreted as a focus change, and it can't do that if the text field inserts TAB. I agree that caret movement should be driven through theNSStandardKeyBindingRespondingmethods, however. I realize that those two statements are at odds with each other, which is why we need to do some design work around this, as Stuart said. It may be that we need another way to represent caret movement, or that on macOS/iOS that there shouldn't be any default bindings on the framework side for caret movement. The developer should still be able to override those key events, however, and even prevent caret movement by overriding those keys if they want to.knopp commentedon Mar 8, 2021
One thing to consider here is that framework may not be able to determine whether arrow key moves caret or selection in candidates menu, so TextInputContext as source of truth might not be optional.
@gspencergoog, I agree completely that framework should have first go at the keyboard event and then pass it on. I do realize that this requires a lot more thinking upfront so I wasn't even trying to implement it :) The positioning of menu on the other hand is lot more straightforward.
knopp commentedon Mar 8, 2021
Also, regarding the input being stuck in compositing mode, I have this: flutter-team-archive/engine#24866 . Not sure if there is any better way to fix it, there doesn't seem to be any specific notification from system to end compositing.
cbracken commentedon May 4, 2021
At this point, the remaining known issues on macOS are:
YeungKC commentedon Jul 27, 2021
related to #85328
cbracken commentedon Sep 28, 2021
Closing in favour of the two remaining issues listed above.
github-actions commentedon Oct 12, 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.