Skip to content

Conversation

@bombizombi
Copy link

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.

@avaloniaui-bot
Copy link

You can test this PR using the following package version. 12.0.999-cibuild0060425-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

@cla-avalonia
Copy link
Collaborator

cla-avalonia commented Nov 28, 2025

  • All contributors have signed the CLA.

@Gillibald
Copy link
Contributor

It looks like we might want to handle insertCompositionText as well.

insertReplacementText is also a candidate that might be needed for replacements

@bombizombi
Copy link
Author

I managed to reproduce wrong behavior.

@MrJul MrJul added bug os-browser backport-candidate-11.3.x Consider this PR for backporting to 11.3 branch labels Nov 28, 2025
@avaloniaui-bot
Copy link

You can test this PR using the following package version. 12.0.999-cibuild0060557-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

@emmauss
Copy link
Contributor

emmauss commented Dec 2, 2025

Please clean up your commit history and rebase over master

@bombizombi
Copy link
Author

@cla-avalonia agree

@bombizombi
Copy link
Author

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?

@bombizombi
Copy link
Author

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.

@MrJul
Copy link
Member

MrJul commented Dec 5, 2025

@bombizombi Thank you for your contribution. Before we can review it or give any advice, as mentioned above, you need to merge master back into your branch, or alternatively rebase. It looks like you've cherry picked the various commits from master, making the diff very difficult to follow.

@bombizombi bombizombi force-pushed the browserMobileKeyboardFix branch from 3c9362b to ec130f5 Compare December 5, 2025 19:48
@avaloniaui-bot
Copy link

You can test this PR using the following package version. 12.0.999-cibuild0060655-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

@xXBuilderBXx
Copy link

xXBuilderBXx commented Dec 11, 2025

Thanks for the fix this really does need patching to v11 because all chromium based mobile browsers essentially don't work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport-candidate-11.3.x Consider this PR for backporting to 11.3 branch bug os-browser

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants