-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Process the hardware enter key as "Done" #16386
Conversation
What is the platform default behavior? Does Android process the hardware keyboard "Enter" key the same way as the software keyboard "Enter" key on Done? |
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
f3a9af5
to
b83dd72
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question below, and I think it would be helpful to add a test here to ensure the Completed event gets fired when we want it to. Otherwise LGTM!
1f8b0db
to
4871aa6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Good candidate for a manual test.
Would be good to re-test this scenario after #17463 gets fixed
What are we doing with this one? |
Hi @PureWeen. We have added the "s/pr-needs-author-input" label to this issue, which indicates that we have an open question/action for you before we can take further action. This PRwill be closed automatically in 14 days if we do not hear back from you by then - please feel free to re-open it if you come back to this PR after that time. |
6fcb7f0
to
893df1d
Compare
/rebase |
b648f02
to
58c717d
Compare
// On API 34 it looks like they fixed the issue where the actionId is ImeAction.ImeNull when using a keyboard | ||
// so I'm just setting the actionId here to whatever the user has | ||
if (actionId == ImeAction.ImeNull && evt?.KeyCode == Keycode.Enter) | ||
{ | ||
actionId = currentInputImeFlag; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So for pre api34 now - if we check the actionId on the entrys, after the action is completed, it should no longer say the actionId is null and instead show the expected one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still just a bit confused because that's my interpretatin of your comment and also because I'm seeing this code both here, and in EntryHandler.Android.cs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! As discussed offline, todos include:
- Ensuring this is well reflected in the manual tests; if it indeed exists, ensuring it becomes activated for Android
- Cleaning up the Debug statements in the PR
- Fixing up the PR description to accurately reflect the fix being made: Entry_Completed gets triggered when pressing the hardware enter key on Android pre-api34 (already happening on api34+ due to android API changes)
once that's all cleaned up, this should be good to go!!!
0fbba96
to
2c187cc
Compare
/rebase |
baeea2c
to
81b99f4
Compare
/rebase |
82b248a
to
2ecd219
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Description of Change
Alternative PR from #14972
This makes android fire completed anytime a user hits the enter key. This behavior now matches iOS and Windows when hitting the enter key on a physical keyboard. This behavior is still different than XF because the focus will still move to the next input control. I realize that behavior will somewhat frustrate XF migration, but keyboard users expect the keyboard to navigate forward so for us to break that default behavior for keyboard users isn't ideal. If the developer wants the entry to capture the keyboard then it's on them to subscribe to the platform view and mark the event as handled.
We'll still need the manual tests because from what I can tell we can't write an automated test for WinUI/iOS/Catalyst
The ultimate fix here would probably be to add our own EditorActions or once we actually have keyboard events in MAUI then users could just interpret these events themselves.
Issues Fixed
Fixes #13921
Fixes #18370