Welcome Guest Search | Active Topics | Sign In | Register

EO.WebBrowser v23 and on-screen keyboard Options
JW
Posted: Friday, March 3, 2023 10:00:57 AM
Rank: Advanced Member
Groups: Member

Joined: 2/8/2019
Posts: 57
We use EO.WebBrower on a touchscreen Windows tablet running Windows 10.

On v22.2.49 when you press an input box that has a type of "number" then the virtual on-screen keyboard appears and displays the numeric keypad by default.

When we move to v23.0.18 or newer, instead it comes up with the stock keyboard (i.e. a-z) and you have to manually swap to the numeric keypad.

I assume this is to do with the move to a newer build of Chromium between the two releases of EO?

For reference, we are using the following HTML:
<input type="number" placeholder="000000" autocomplete="off" maxlength="10">

Is there any way to get the numeric keypad displayed again?

Thanks
JW
Posted: Friday, March 3, 2023 10:13:37 AM
Rank: Advanced Member
Groups: Member

Joined: 2/8/2019
Posts: 57
I'm not sure if this is relevant or not, but if I shift focus out of the app around enough, it appears to start working. It's not completely clear what triggers it to start working, but if I run with the DevTools displayed, opening them (and the Chrome tools) and then giving focus back to the app results in the correct keyboard being displayed.

Also, setting inputmode="numeric" on the HTML element doesn't seem to help.
JW
Posted: Friday, March 3, 2023 10:20:53 AM
Rank: Advanced Member
Groups: Member

Joined: 2/8/2019
Posts: 57
Last one for now (sorry!). I've just tried with the TabbedBrowser in v23.1.25 and it's the same.

Create an index.html that contains nothing more than:
<input type="number" placeholder="000000" autocomplete="off" maxlength="10">

Browse to this using Tabbed Browser.

Click on the input box and the a-z keyboard is displayed. Click out of the app back to Windows and click back to TabbedBrowser, then click on the input box and the numeric keyboard is displayed.

Reload the page using the load circular arrow button (leaving leave TabbedBrowser open) and the keyboard goes back to the a-z one.
eo_support
Posted: Wednesday, March 8, 2023 10:37:44 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

This is just to let you know that we are still working on this issue. We are able to reproduce it but have not been able to find out the root cause yet. We will reply here again once we have an update.

Thanks
JW
Posted: Friday, March 17, 2023 12:10:45 PM
Rank: Advanced Member
Groups: Member

Joined: 2/8/2019
Posts: 57
Thanks for looking into this. Sorry to pester, but have you been able to make any progress?
eo_support
Posted: Friday, March 17, 2023 4:42:22 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
No. We have not made any progress yet. We did trace into the corresponding Windows API and it appears that they have been called correctly. We will continue to work on this and reply here again as soon as we have an update.
JW
Posted: Tuesday, April 11, 2023 8:27:42 AM
Rank: Advanced Member
Groups: Member

Joined: 2/8/2019
Posts: 57
Hi, just wondering if there has been any update on this?

As you've traced the calls to the Windows API, is it possible to see what is being passed differently in v23 when compared to v22.2.49 (which I believe is the last version this worked)?

Thanks.
eo_support
Posted: Tuesday, April 18, 2023 10:34:37 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

Please download build 23.1.77 from our download page and see if it works for you. We made some code changes and it appears to work much better during our test environment.

Thanks!
JW
Posted: Friday, April 21, 2023 8:27:39 AM
Rank: Advanced Member
Groups: Member

Joined: 2/8/2019
Posts: 57
I'm sorry, but I'm seeing the same behaviour with the 23.1.77 release.

If I use TabbedBrowser and click on an input element with a type of "number", then I get the normal keyboard. If I give the focus back to the Desktop and then try again, I get the correct numeric keyboard displayed.
JW
Posted: Monday, May 15, 2023 6:54:38 AM
Rank: Advanced Member
Groups: Member

Joined: 2/8/2019
Posts: 57
As this functionality was lost with an update to Chromium, I wonder if another update may restore it.

Do you have timescales for when you are next likely to update Chromium again?

Thanks.
eo_support
Posted: Monday, May 15, 2023 11:27:29 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
We will have another update either this week or next week based on Chromium v111.
JW
Posted: Thursday, May 25, 2023 10:46:51 AM
Rank: Advanced Member
Groups: Member

Joined: 2/8/2019
Posts: 57
This is still an issue with v2023.2.14.

Please, could this be looked at again? If it helps, I can provide a video of the issue using TabbedBrowser?
eo_support
Posted: Thursday, May 25, 2023 1:57:49 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Certainly. However our website does not accept large files --- so you may want to post it online and then share the link with us through our contact us page.
JW
Posted: Friday, May 26, 2023 11:41:32 AM
Rank: Advanced Member
Groups: Member

Joined: 2/8/2019
Posts: 57
Thanks, I've posted the links using the contact us page.
JW
Posted: Friday, June 9, 2023 6:14:16 AM
Rank: Advanced Member
Groups: Member

Joined: 2/8/2019
Posts: 57
Hi, just wondering if you had received the video clips showing the issue? Thanks.
eo_support
Posted: Friday, June 9, 2023 4:22:16 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Yes. We did receive the videos and we can reproduce the problem. However are still not able to find out the root cause yet. :(
eo_support
Posted: Tuesday, June 27, 2023 9:21:56 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Sorry that it took a while. Please download build 23.2.48 from our download page and see if it resolves the issue for you. We tested it here and it seems to work correctly.
JW
Posted: Wednesday, June 28, 2023 8:13:23 AM
Rank: Advanced Member
Groups: Member

Joined: 2/8/2019
Posts: 57
Thanks for the work on this, we do appreciate your effort on this one.

I've done some quick testing and have a mix of good and bad results.
- The good: It seems that a input element with a type of "number" does indeed bring up the correct keyboard.
- The bad: The sizing of the application when the keyboard is shown is now behaving rather strangely.

We run our app in fullscreen, with a WPF grid with two rows. The top half of this grid (i.e. the first row) is for the web view. Normally, this fills a set portion of the screen, say 300px. The bottom half of this grid (i.e. the second row) takes up any remaining space (WPF height of "auto").

In this new build of EO, if we open the keyboard, it appears that the webview inside the grid takes on a size that matches the whole screen while the keyboard is displayed (i.e. we can scroll the content of the webview up/down). When the keyboard is closed, it reverts to the correct size.

It's a bit hard to see what is going on, but it appears the root HTML element is being resized, although the body isn't (i.e. if I colour the HTML background and body background differently, open the keyboard and scroll up, the additional area takes on the colour applied to the HTML element rather than the body element).

It also appears that the clientHeight/window.screen.height are not changing (hard to tell, as if I click off to look at the Chrome Debugger the keyboard hides itself).

Any thoughts?
eo_support
Posted: Wednesday, June 28, 2023 9:47:17 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

This appears to be that the full screen Window element is not resized properly. Because EO.Wpf.WebControl is just a child control inside the Window, it will NOT manage the Window element's size. In another word, it only responds to Window element's size change, not initialize a size change for the Window element. As such you have to have additional code to respond to the touch keyboard show/hide event and then change your Window size accordingly. Fortunately, Microsoft has published some sample code that does exactly just that and you can simply reference the sample DLL and use it:

https://github.com/microsoft/WPF-Samples/tree/main/Input%20and%20Commands/TouchKeyboard

Please let us know if this resolves the issue for you.

Thanks!
JW
Posted: Wednesday, June 28, 2023 9:58:57 AM
Rank: Advanced Member
Groups: Member

Joined: 2/8/2019
Posts: 57
Thanks, but that is the issue. We already have implemented that code and it has been working fine for the last few years worth of releases of EO. We have touch aware decorator and respond to the keyboard coming and going.

As a full screen app (actually running in Kiosk mode), we can't reduce the size of our window, so the way to handle this is to resize web view (using a Grid) to make sure the keyboard doesn't occlude it (i.e. the app is still full screen, but the grid is adjusted so the web view becomes "shorter" to give space to the keyboard underneath it).

This still works, but the web view itself now gets it's size wrong when the keyboard is present (and only when the keyboard is present). It no longer respects the size of the grid that it is contained within, and seems to think it is now the size of the screen.


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.