-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Partially fixes #11665, virtual keyboard or Browser mobile android fix #20166
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
base: master
Are you sure you want to change the base?
Conversation
|
You can test this PR using the following package version. |
|
|
It looks like we might want to handle
|
|
I managed to reproduce wrong behavior. |
|
You can test this PR using the following package version. |
|
Please clean up your commit history and rebase over master |
|
@cla-avalonia agree |
|
I need some advice on 3 things. I created some more handling for the mobile keyboard (GBoard) on android. This patch just alows basic typing to work, but it has some problems, in cases where the keyboard tries to autocorrect previous text, or insert suggestions. Those other features are currently in another branch, mixed with a lots of logging code. The new code handles those cases. And in those changes I had to change more things around, and right now this new code detects the virtual keyboard by those (Unknown, code 229) messages. I also changed the code in the TextBox itself, since the "InputMethod" code is trying to copy the state into the hidden control, and TextBox was giving it the wrong state. TextBox is clearing selection by just setting the start and end of selection to the same position, which means no selection, but it sets it in a wrong place (one character too early), so I changed it. Still, this might affect every other platform if somebody relies on this internal behavior. So, I'm not sure this change was a smart thing to do. Also, is there a standard way of handling or detecting platform abilities? Right now, I just switch to "IME" mode, and there is no going back after the detection is done. Without this state change, composition events couldn't be processed. (Or maybe I just didn't find a way.) So, this other change, should I push this update, should I create a new PR for it all? Is there perhaps an Avalonia experimental branch? |
|
Now I understand the TextInputMethod classes a little better, so no need for changing messing with the basic classes. Also subscribed to the SelectionChanged event, this was a big source of desyncing between Avalonia control and the hidden input control. |
|
@bombizombi Thank you for your contribution. Before we can review it or give any advice, as mentioned above, you need to merge |
3c9362b to
ec130f5
Compare
|
You can test this PR using the following package version. |
|
Thanks for the fix this really does need patching to v11 because all chromium based mobile browsers essentially don't work. |
This partially fixes issue #11665, where no keypresses are recorded on android virtual keyboards. The sequence of events differ like this:
Key sequences, desktop Chrome
Key "a" pressed [event: keydown]
Key "a" about to be input [event: beforeinput]
Key "a" input [event: input]
Key "a" released [event: keyup]
android browser chrome virtual keyboard
Key "Unidentified" pressed [event: keydown]
Key "a" about to be input [event: beforeinput]
Key "a" input [event: input]
Key "Unidentified" released [event: keyup]
The event is documented here: https://developer.mozilla.org/en-US/docs/Web/API/Element/beforeinput_event
Since Avalonia is marking the keyDown event as handled (preventDefault or javascript side) the beforeinput does not fire on desktop browser.
So, typing work the same as before on desktop browser.
The official documentation says the mobile events from IME keyboards should be handled with input, beforeinput, and composing events. InputEvent interface has about 50 possible values for the inputType (https://w3c.github.io/input-events/#interface-InputEvent-Attributes), and here we are ignoring 48 of them.
How was the solution implemented (if it's not obvious)?
Debugging by instrumenting code and logging over HTTP.
Checklist
No tests.
Breaking changes
Possible.