Hi, with the latest Chromium version, on a touchscreen, when tapping a field on a web page, the keyboard displays for about 3 seconds then closes.

This only happens with the older onscreen keyboard - if you are running the latest Windows 10 you will need to add the following registry value and reboot.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TabletTip\1.7
REG_DWORD
[DisableNewKeyboardExperience] = 1


I was able to recreate the problem with TabbedBrowser - the only change I made is setting AlwaysShowOnScreenKeyboardOnTouch to true.

This does not happen if I tap on a text field outside a web view.

Thank you

So are you saying this issue is somewhat related to AlwaysShowOnScreenKeyboardOnTouch? I set this true because my only touchscreen computer has a physical keyboard. Do you think there will be a fix for the keyboard closing? Thank you.

Unfortunately I don't know how to avoid the problem other then reverting to a previous version of EO.WebBrowser. Can you please clarify as to what you are going to rollback? Are you rolling back the change that is causing the problem I describe?

As an alternative "solution" I could imagine having an event on the WebView (ex. OnInputFocus() / OnInputBlur() or something like that) that gets triggered when user touches a textbox in HTML.

This could give us a way to show a custom onscreen- keyboard. We could then solve the problem ourselves. ;)

Hi,

We have posted a new build that removed AlwaysShowOnScreenKeyboardOnTouch property but added FocusedNodeChanged event. You can download the new build from the download page. Please take a look and let us know how it goes.

Thanks!

Hi,

FocusedNodeChanged and AlwaysShowOnScreenKeyboardOnTouch are not a one for one exchange. Here is the background information:

1. Chromium browser engine will try to automatically display the on screen keyboard when an editable field is in focus. This works well most of the time but does not work on some systems;
2. We tried to add AlwaysShowOnScreenKeyboardOnTouch to "enhance" this but ran into even more problems;

This leads us to remove AlwaysShowOnScreenKeyboardOnTouch. In another word, we no longer officially support any on screen keyboard manipulation. As to the new FocusedNodeChanged event:

1. It is not meant to "make up" for AlwaysShowOnScreenKeyboardOnTouch or bring whatever feature lost through AlwaysShowOnScreenKeyboardOnTouch back. That feature has been removed because it does not work reliably on all systems.
2. Nevertheless, it does give you an opportunity to "fix" whatever problems you might have with the on screen keyboard. However that will be completely up to you. You may find a way to make it work on a specific system since the trouble we ran into was we could get it work on some system but not all systems.
3. Beside manipulating on screen keyboard, it may also be used for other purpose. For example, it can be used to enable/disable menu/toolbar items.

When you put these together, you are not on the wrong path to take advantage of the new FocusedNodeChanged event. But it would be wrong for you to expect FocusedNodeChanged is meant to make up for AlwaysShowOnScreenKeyboardOnTouch. It is not. It is one of thing we added that you may find helpful for your purpose but may also be used for other purposes. And you may need to have additional code to detect/fix up other scenarios (such as intercepting tapping when a field already has focus) in order for it to work perfectly for you. Those additional scenarios may not have anything to do with FocusedNodeChanged event at all.

Hope this clears it up a bit for you.

Thanks!