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.

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

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.

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!

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.

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?

Thanks, I've posted the links using the contact us page.

Yes. We did receive the videos and we can reproduce the problem. However are still not able to find out the root cause yet. :(

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?

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.