Skip to content
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

On screen keyboard not opening when directly switching between inputs #460

Closed
pconfig opened this issue Sep 21, 2020 · 34 comments
Closed

On screen keyboard not opening when directly switching between inputs #460

pconfig opened this issue Sep 21, 2020 · 34 comments
Labels
bug Something isn't working tracked We are tracking this work internally.

Comments

@pconfig
Copy link

pconfig commented Sep 21, 2020

Description
When i put my PC in tablet mode, I get an on screen keyboard whenever I tab an input field. This also works correctly in WebView2. However when i switch between input fields directly without letting the first input field lose focus, the on screen keyboard disappears and only comes back when the focus is put to a non input field.

Version
SDK: 0.9.628-prerelease
Runtime: Edge dev 87.0.637.0
Framework: WPF
OS: Windows 10

Repro Steps
Open a simple web page with multiple input fields
Put your Windows 10 PC with touchscreen in tablet mode
Touch the first input field -> On screen keyboard pops up
Touch the second input field -> On screen keyboard goes away and never comes back unless focus is put to a non input field

AB#29514590

@pconfig pconfig added the bug Something isn't working label Sep 21, 2020
@champnic
Copy link
Member

Does this also repro in the standalone Edge browser?

@pconfig
Copy link
Author

pconfig commented Sep 21, 2020

I just checked. The behavior in standalone edge is not perfect either but is slightly better.

When i tap on another input the virtual keyboard also disappears but it reappears when tapping the same input again. This is not the case with WebView2

@champnic
Copy link
Member

Thanks for verifying that this is limited to WebView2. I've opened an item for us to track and we'll take a look. Thanks!

@champnic champnic added the tracked We are tracking this work internally. label Sep 21, 2020
@pconfig
Copy link
Author

pconfig commented Oct 26, 2020

Do you have any update on this issue?

Thanks

@tofuandeve
Copy link
Contributor

Hi @pconfig , I'm working on this issue and this doesn't seem to repro for me. On WPF app, I navigated to Facebook.com, touching in the email edit field brought up the touch keyboard, and it didn't go away when switching directly between the password and email fields. Touching outside the edit fields did dismiss the on screen keyboard, and touching back in the input field brought back touch keyboard.

Version
SDK: 1.0.721-prerelease
Runtime: 88.0.705.53
Framework: WPF
OS: Windows 10

Could you try out if you are still able to repro using latest WebView2 bits? If this still repros, we'd like to get some more detail on the repro steps. Thanks!

@gdsl1988
Copy link

gdsl1988 commented Mar 3, 2021

@tofuandeve I'm also having this issue,

Version
SDK: 1.0.664.37 but have had same issue with 1.0.790-prerelease
Framework (.NET 5.0)
Edge Version 89.0.774.45 (Official build) beta (64-bit)
OS: Window 10 Enterprise LTSC v 1809 and Windows 10 Enterprise 2016 LTSB 1607

I'm running a windows app with a webview2 control being the only control on a form, displayed full screen, borderless. The app runs on a touchscreen on a pc set up as tablet mode. There is a physical keyboard and mouse attached in most cases but hidden away from our users.

The on screen keyboard will only work when you first touch the screen in any space that has no controls, then pressing a control will bring up the keyboard. You must then touch away from any controls again to use the on screen keyboard on the next input.

Touching inside the control you have just used the keyboard for also dismisses it, but in this case, again it won't then work for the next input without also pressing on an area of the screen without a control...

Also, the keyboard is dismissed on each key press of the osk. This is in addition to the above problem and only on the machine running Windows 10 Enterprice 2016 LTSB

@tofuandeve
Copy link
Contributor

Hi @gdsl1988 I'm looking into this but couldn't get the same behavior you are getting on my test machines(Surface laptop 3). Could you please provide some information about the machine(s) you are using:

  • What type of machine(s) does this bug happen on? (for example: surface laptop, all in one pc, etc.)
  • Can you elaborate more about having physical keyboard "hidden away from users"? Can you remove/detach the physical keyboard completely? Does this still happen when you detach the physical keyboard?

@OJapes
Copy link

OJapes commented Mar 24, 2021

Hi,

I can also reproduce this problem. It does not change when detaching the physical keyboard.
Other areas of the WPF-Application behave as expected.

What I want to add is that in my case, the application is set to TopMost and it makes no difference if I'm using tablet mode or not.

The PC I'm using is a LattePanda with a touchscreen.

@tofuandeve
Copy link
Contributor

@gdsl1988 @OJapes @pconfig Hi ya'll, we are working on this issue but having problem with reproing the bug. We tried different touch screen devices (with and without a detachable keyboard) but still couldn't get this to repro.
Can you try to repro this on our sample app in here. We appreciate it!

@OJapes
Copy link

OJapes commented Apr 12, 2021

Hi @tofuandeve
We've just confirmed that the behavior using the sample app is the same as for our application.
What I might add is that our machines are running on Enterprise 1607 (LSTB)

@OJapes
Copy link

OJapes commented May 5, 2021

Hi @tofuandeve and @champnic,

are there any updates on this problem?

@tofuandeve
Copy link
Contributor

Hi @OJapes , we're still working on investigating this bug. Can you verify really quick which hosting mode is this bug reproducing for you: Is it cross-proc HWND mode or visual hosting mode?

@OJapes
Copy link

OJapes commented May 6, 2021

Can you verify really quick which hosting mode is this bug reproducing for you: Is it cross-proc HWND mode or visual hosting mode?

I'm not sure on how to determine that. I've just scratched the surface of this control using WPF.
When I'm starting the sample app on the target machine, the task manager shows separate entries. One for the main application, and several for the webview (see screenshot below)
Clipboard01

If you can give me some instructions I'd be happy to verify it correctly.

@champnic
Copy link
Member

champnic commented May 6, 2021

If you are using the WPF control then you are using the HWND hosting mode. To use visual hosting in .NET requires essentially building you own control on top of the CoreWebView2 APIs at this point. Thanks for the info!

@OJapes
Copy link

OJapes commented May 18, 2021

@champnic What does that mean in regard to the "disappearing keyboard"-problem? Do I have to change/add anything in my control (I've already wrapped the WebView), or does anything else has to be changed in the webview-code itself? Just tell me if I can be of any further help, as we've got a great interest in using WebView2.

@champnic
Copy link
Member

Appreciate the offer @OJapes! We had recently fixed an issue with the virtual keyboard that only occurred in visual hosting mode (using WindowsComposition), but you are using HWND hosting mode and so unfortunately it's a different issue we are still looking into. I believe @tofuandeve is able to reproduce the issue, so now it's a matter of tracking down the root cause.

@pconfig
Copy link
Author

pconfig commented Jul 19, 2021

How is the tracking down working out?

@OJapes
Copy link

OJapes commented Oct 21, 2021

This problem still exists in 94.0.0992.50. Any further progress on that?

@OJapes
Copy link

OJapes commented Nov 17, 2021

Hi! It's quite quiet around here lately. Can you give us a small update whether we can expect a fix for this?

@tofuandeve
Copy link
Contributor

Hi @OJapes , we has been trying on many different test devices but still couldn't get this bug to repro. Could you provide some more information on how you get it to repro on the our WPF public sample app?

I tried to repro this with these steps in 95.0.1020.53 This is my flow:

  1. Clone public sample apps, build the wpf sample app on visual studio.
  2. Launch the sample app, navigate to facebook.com.
  3. Detach the physical keyboard. (I tried both detach keyboard after and before launching the wpf sample app)
  4. Touch the first (email) input field and observe: OSK showed up.
  5. Touch the second (password) input field and observe: OSK still showed.
  6. Touch back to the first input field, OSK still showed.

Is there any thing I'm missing? Would it be possible if you can provide us your sample app so we can test it out?

@adamfierek
Copy link

Hi @tofuandeve. It does work until you close OSK. To open it again, you have unfocus and focus input again. It does not work like that on other browsers, even on Microsoft Edge in Windows 10 and 11. We done some tweaks in our web app to manage element's focus but no luck. Please look at this issue again.

I have tested your WPF sample and WinForms as well. Same results.

@jayandran1988
Copy link

Hi @tofuandeve what @kolorowezworki says is the way i also see this problem -> When the keyboard is closed by touching the close button [X]. I have to unfocus (touch somewhere outside) and refocus to the input box to get the keyboard back automatically.

@mallocation
Copy link

@tofuandeve I am also seeing what @kolorowezworki and @jayandran1988 have said. The issue presents itself only after tapping the "X" button to close the touch keyboard. In our scenario, users may accidentally hit the "X" to close when the keyboard is open, and the keyboard no longer reappears as needed.
Here's a JSFiddle that I made to test the problem.

Environment
WPF .NET Core 3.1
WebView2 SDK: 1.0.1108.44
WebView2 Runtime: 101.0.1210.32 (Evergreen)

Repro steps using the above JSFiddle:

  1. Tap to focus in the first text field. The touch keyboard should appear.
  2. Tap the "X" to close the touch keyboard.
  3. Tap to focus in the second text field.

Expected: The touch keyboard should appear.
Actual: The touch keyboard does not appear.

The "Expected" result does occur in Microsoft Edge. The issue only occurs when using WebView2.

@tofuandeve
Copy link
Contributor

Hi all, we finally got a repro for the behavior that @OJapes and @pconfig are seeing, which seems to only happen on some specific older OS versions.

Both behaviors are caused by the same issue and the fix for it went in today, and it should be available in our prerelease package soon in June. Please give it a try and let us know if you run into any issue.

Thanks!

@adamfierek
Copy link

@tofuandeve

I have met with the same problem under the latest stable build of Windows 11. I hope upcoming fix will solve it.

@mallocation
Copy link

@tofuandeve Can you verify that the fix you've mentioned will also address the issue of the keyboard no longer showing after tapping the "X" to close the keyboard? Or, would would like us to enter a separate issue? Thanks!

@tofuandeve
Copy link
Contributor

@mallocation Yes, we have confirmed that it fixes the issue virtual keyboard doesn't show up after user presses X button to close the keyboard.

@mallocation
Copy link

@tofuandeve That's great news, thanks for following up! We look forward to trying that in June.

@ivanpedruzzi
Copy link

I have been chasing the same problem on Chome Embedded framework, I can see that CEF does not receive the COM event notification when the OSK is closed. The keyboard controller class "VirtualKeyboardControllerWin" tracks the visibility state with the data member "virtual_keyboard_shown_", when the user clicks on the X to close the OSK, keyboard controller still thinks that the keyboard is visible and does not pop it back.

The following method is the callback supposed to be called when the OSK is closed on COM event.

HRESULT OnScreenKeyboardDisplayManagerInputPane::VirtualKeyboardInputPane::OnInputPaneHidden

Notice that both full Edge and full Chome do not have the problem.

My guess is that the thread that is supposed to pump the message either is not created or created differently in CEF and WebView2

If the authors of the fix could explain the fix I would extremely appreciated .

@tofuandeve
Copy link
Contributor

Hi @ivanpedruzzi , the issue was indeed due to the virtual_keyboard_shown_ not getting updated after the virtual keyboard is hidden by user closing it with the X button.

When the virtual keyboard is manually closed by the user, the |virtual_keyboard_shown_| flag should be reset in VirtualKeyboardControllerWin::OnKeyboardHidden. This flag then will be used to determine whether TryShow needs to be called or not to avoid flickering. However, when this happens in WebView, the hiding event is sent to the app process instead, and the VK input pane doesn't notify VirtualKeyboardControllerWin to reset this |virtual_keyboard_shown_| flag. This causes the virtual keyboard controller observer to think that the virtual keyboard is still showing and does not bring the keyboard back up.

We made a fix to handle this properly, if you need more information about the fix, feel free to reach out at le.eve@microsoft.com

Thanks!

@champnic
Copy link
Member

champnic commented Jun 9, 2022

This is fixed in runtime versions 102.0.1249.0+. Thanks!

@ivanpedruzzi
Copy link

@champnic is the update already public? where we can download it?
Thanks!

@champnic
Copy link
Member

Yes it's already public. If you are using the evergreen runtime then it will be automatically downloaded and is in the current stable WebView2 Runtime. If you are using Fixed Version or otherwise need to install the runtime, please see here:
https://developer.microsoft.com/en-us/microsoft-edge/webview2/

Thanks!

@mallocation
Copy link

This is working great! (tested with evergreen, version 103.0.1264.37) Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working tracked We are tracking this work internally.
Projects
None yet
Development

No branches or pull requests

9 participants