-
Notifications
You must be signed in to change notification settings - Fork 7
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
Wrong handling of certain input events #96
Comments
I've been able to do some debugging and I'll dump here some logs that think would be useful to investigate the root cause of the issue. These are the Chromium calls when clicking on the first text box to show the virtual keyboard, followed by typing the "5" key:
These are the logs combining the Android (Wolvic) and Chromium sides:
|
I've added some debug calls to see the DOM tree of the focused element:
|
I've tried the same test case with a Chromium (Linux) build using the same branch we are using for Wolvic. One difference is that the HandleTextInputEvent call receives an underlaying event, while in our Wolvic browser there is no underlaying event and the target is got from the Document. This is the backtrace of the call using the Chromium built, where the test case works as expected:
|
Some "debug" information about a test case that works in Wolvic (eg, teh text field is correctly rendered):
On the contrary, this is the same 'debug' data for the Disney test case that doesn't work:
The difference between these 2 cases seem to be the lack of calls to Editor::HandleKeyboardEvent in the case that doesn´t work. |
This issue is reproducible in Wolvic (Chromium) 0.9 from the current (07d9122) wolvic_experimental branch.
These are the steps to reproduce the issue:
1- Load the https://www.disneyplus.com/identity/login/enter-email URL
2- Introduce an email and press continue
3- Type the numeric code
This specific web page prevents the user to move the focus to a specific text input, so that it's handled by the input event handling. The expected behavior is that typing a numerical value will be renderer in the corresponding input box and the caret and focus is moved to the next element automatically.
Attached a picture of the web page used as test case for the issue:
The text was updated successfully, but these errors were encountered: