search

cefsharp / CefSharp

.NET (WPF and Windows Forms) bindings for the Chromium Embedded Framework
http://cefsharp.github.io/
Other
9.83k stars 2.92k forks source link

windows 8.1 system's virtual keyboard not working with CefSharp / WinForms app #1054

Closed acoder32 closed 6 years ago

acoder32 commented 9 years ago

Context: I'm using CefSharp v39.0.2 to run a HTML5 web app as a winforms application.

Problem: Keyboard input is critical to this app but on win8.1 devices anywhere in the web app text can be entered (into input or textarea elements) the windows 8.1 virtual keyboard events (if a device doesn't have a physical keyboard or you're choosing not to use it) are not appearing in the text element (no characters show up). Clicks on the virtual keyboard are occurring and making click sounds, but characters do not appear in the text input elements. (fwiw, I haven't had the problem on any win7 machines-- text entry works as expected there.)

Most of the time after clicking on a text input element, the virtual keyboard appears as expected but keyboard presses do not enter any text into the element as described above. A few times I've also observed the whole app freeze (window becomes all white and unresponsive and I must kill it in the task manager).

Has anyone else experienced this on windows 8.1 when using the win 8.1 virtual keyboard with CefSharp?

These reported problems seem related but not quite the same problem: https://bitbucket.org/chromiumembedded/cef/issue/985 https://github.com/cefsharp/CefSharp/issues/997 https://github.com/cefsharp/CefSharp/issues/952 http://www.magpcss.org/ceforum/viewtopic.php?f=14&t=10805

Another post suggested using an HTML5 keyboard as a workaround, but I'd really like to avoid adding that complexity and just use the win 8.1's keyboard which I think is the expected way to enter text in win8 apps when you're not using a physical keyboard.

The web app is complex so I am working to produce a barebones project that reproduces the problem. I will continue to debug the problem and welcome ideas on how to fix or debug this issue. I am relatively new to CefSharp-- there may be some debugging approaches more experienced CefSharp uses may suggest. Thank you!

acoder32 commented 9 years ago

Here is a minimal change from v39.0.2 that will exhibit the problem:

  1. On a windows 8.1 device with touch support (e.g., Surface Pro 3) download CefSharp v39.0.2 source (https://github.com/cefsharp/CefSharp/releases/tag/v39.0.2)
  2. in "CefSharp.WinForms.Example" directory, create the file "index.html" and add the HTML below.
  3. Add index.html to project "CefSharp.WinForms.Example" and set index.html's property "Copy to Output Directory" to "Copy if newer".
  4. in CefExample.cs, change DefaultUrl to "file:///index.html"

Build & run. If you use touch to select the textarea, then the cursor will be positioned properly, the textbox will highlight like it has keyboard focus, and the win8.1 virtual keyboard will appear but key presses WILL NOT add text to the textarea. If you use a mouse to click in the textarea then keypresses WILL work.

<!DOCTYPE html>
<html>
    <body>
        <textarea>Click here and type to modify the text</textarea>
    </body>
</html>
rassilon commented 9 years ago

Have you tried this with cefclient? See the suggestions on what to include in an issue.

WinForms generally stays out of the way of keyboard mucking around let alone the Win 8.1 onscreen keyboard. I wouldn't be surprised if this is an upstream CEF issue.

This really seems like #985, I'm afraid.

Oddly enough, Raymond Chen posted a blog today along these general lines.

CefSharp wouldn't want to automatically do what Raymond is suggesting without further support to ensure the text control is still visible when the keyboard is displayed.

Bill

acoder32 commented 9 years ago

Bill, thank you for your suggestions. Comments below:

Have you tried this with cefclient?

cefsharp v39.0.2 uses cef.sdk.3.2171.2069 . Using http://www.cefbuilds.com branch 2171 with this command:

cef_binary_3.2171.2069_windows32_client\Release\cefclient.exe --url="file:///index.html"

works correctly. On a Surface Pro 3 clicking in the text box positions the cursor as expected, the win8.1 virtual keyboard appears, and typing virtual keys inserts the appropriate characters into the textarea element. This seems to suggest the problem may be in CefSharp and some difference between it and cefclient.

This really seems like https://bitbucket.org/chromiumembedded/cef/issue/985, I'm afraid.

In that issue they are saying the virtual keyboard does not appear. In this issue, the virtual keyboard does appear. The problem is characters are not appearing in the selected text field after typing keys on the virtual/touch keyboard.

Oddly enough, Raymond Chen posted a blog today along these general lines.

Raymond says touch keyboard does not appear automatically. With both cefsharp v39.0.2 and cefclient v3.2171.2069 and the example HTML file the touch keyboard does automatically appear. So these do not seem related.

Thank you again for your help. I will pursue the insight from your suggestion to test with cefclient-- trying to understand the differences between cefclient and CefSharp example apps which have different behavior.

jornh commented 9 years ago

Bill said:

WinForms generally stays out of the way of keyboard mucking around let alone the Win 8.1 onscreen keyboard. I wouldn't be surprised if this is an upstream CEF issue.

Well not completely, at least some additional handling is added in CefSharp's WinForms wrapping layer: https://github.com/cefsharp/CefSharp/blob/master/CefSharp.WinForms/Internals/DefaultFocusHandler.cs

@acoder32 I'm speculating if the touch-click even you describe above versus mouse-click behaviour fires different events and it conflicts with CefSharps additional layer of focus handling. Note this is mostly hunches from my end, still throwing it out in the hope it can lead you closer to a solution. :meat_on_bone:

rassilon commented 9 years ago

@acoder32 , Have you tried cefclient with the multithreaded message loop? CefSharp always uses the multithreaded message loop. (CEF is one thread A, while the WinForms/WPF UI is on thread B).

@jornh: I suppose it's possible for that focus/activation adaptation logic could be part of the problem. I would be fairly surprised though.

Bill

rassilon commented 9 years ago

Sadly, my Surface Pro 3 doesn't even have Visual Studio on it atm, and has currently been borrowed by testing, otherwise I might have taken a gander today. :frowning:

Bill

amaitland commented 9 years ago

I suppose it's possible for that focus/activation adaptation logic could be part of the problem. I would be fairly surprised though.

My first though was Focus related, so I'd say it would be worth just setting FocusHandler = null to see what happens by default.

AJDev77 commented 9 years ago

I'm speculating if the touch-click even you describe above versus mouse-click behaviour fires different events and it conflicts with CefSharps additional layer of focus handling.

You could be right, as I have tested this on my Transformer Book T100, without the keyboard dock, and I do think it has to do something with the Focus. When I first start my browser, I don't focus anything (by using .Focus). When running on my T100, it always focuses the address bar TextBox first. When I tap on the DuckDuckGo search box, the virtual keyboard does come up, but when I type, it continues typing in the address bar TextBox, not the DuckDuckGo search box.

I decided to test this out more, so I added browser.Focus on FrameLoadEnd, so it would focus on the browser control whenever it finished loading a web page. When I ran it again on my T100, at startup when it finished loading the first web page, it focused on the browser control, because the blinking cursor in the address bar TextBox was gone. I could then tap on the search box and type into it using the virtual keyboard. Also, when I tap back on the address bar TextBox, I can type in the address bar using the virtual keyboard, but then when I tap back on the search box, it brings up the virtual keyboard, but when I type, it continues typing in the address bar, so I would think this would have to be a problem with Focus.

amaitland commented 9 years ago

Does setting FocusHandler = null change anything? (Effectively removing the default handler).

AJDev77 commented 9 years ago

Where would I set this? (I am using VB, not C#...)

I tried to experiment a little bit, and where I initialized the browser control, I added Me.browser.FocusHandler = Nothing, but I heard that Nothing in VB just sets it to the default, and when I used null, it would come up with an error. Anyway, when I started my browser, the address bar TextBox was not in Focus anymore, so I am assuming it did something. Let me try to run it on my T100 and see what happens.

Edit: Just ran in on my T100, and at the beginning when the browser launches, the browser control has Focus, so I can type in the search box, but when I tap on the address bar TextBox, and then tap back on the search box, it still does the same thing. That might be because I am not setting it to null, but as I said before, that was not working in Visual Studio, it just kept giving an error before it launched.

amaitland commented 9 years ago

Where would I set this? (I am using VB, not C#...)

Can't really help with VB syntax sorry.

If you build from source you can comment out the assignment.

https://github.com/cefsharp/CefSharp/blob/master/CefSharp.WinForms/ChromiumWebBrowser.cs#L87

AJDev77 commented 9 years ago

Okay, I will comment out that line and then build from source again. I will have to do it later, when I get home though.

acoder32 commented 9 years ago

Thank you everyone for your many suggestions. I have not had time to pursue them all yet. However, I wanted to share that this post #684 related to focus has helped make it work for me. In particular it says:

adds a SetFocus() method that you can call on the ChromiumWebBrowser that sets focus to the browser. Prior to this it wasn't possible to set focus programmatically; only a mouse-click worked.

To me this is a workaround as why should a mouse-click do more than a touch-click in terms of focusing a control, but for the moment it has addressed my immediate need but I wouldn't call this resolved.

rassilon commented 9 years ago

I looked at #684, but I couldn't quite tell when they suggested calling SetFocus on the ChromiumWebBrowser. i.e. in response to what event do you call SetFocus?

Additionally, if you want to debug the underlying issue further you could put in the code I removed in the focus fixing PR. The logging logs most of the focus/activation troublesome areas of interaction.

Sadly, my Surface Pro 3 is still on lone to my team's tester. :frowning:

Bill

rassilon commented 9 years ago

Well, I have happy/sad news to report. I've seen this happen with a password like UI on my Surface Pro 3, but only part of the time. I set FocusHandler to null in my app and it appears to now work all of the time. :sob:

Since I'm only dealing with a full screen Kiosk app, I think that's how I'll leave my app for now, but I'm going to put the focus logging goo back in on master soon. Hopefully, that will help us fix this issue.

Fyi, Bill

amaitland commented 6 years ago

For those experiencing this issue integrating CEF into your applications message loop and setting FocusHandler = null should resolve the problem.

https://github.com/cefsharp/CefSharp/wiki/General-Usage#multithreadedmessageloop

You test using the WinForms example, change the value at https://github.com/cefsharp/CefSharp/blob/cefsharp/65/CefSharp.WinForms.Example/Program.cs#L62

You may need to implement your own custom IFocusHandler that calls IBrowserHost.SetFocus(true) to workaround a CEF bug.

https://bitbucket.org/chromiumembedded/cef/issues/1797/windows-touch-does-not-return-focus-to-the#comment-33667739

You may also need to use the disable-usb-keyboard-detect command line arg if your not seeing the keyboard popup, see #1691 for details.

amaitland commented 6 years ago

Closing this for now, if someone wants to take ownership and resolve the problem then by all means. I'm fairly confident that integrating CEF into your existing message loop will solve any problems.

CEF still has some touch related focus issues like https://bitbucket.org/chromiumembedded/cef/issues/1797/windows-touch-does-not-return-focus-to-the which will need to be fixed upstream.