Thanks for filing the issue!

Able to reproduce the issue on reported chrome version 67.0.3396.87 using Windows 10 1803 surface pro, as the issue seems to be fixed in latest canary 69.0.3464.0 marking it as Untriaged. Will update the bisect info soon. Hence adding label Needs-Bisect.

Able to reproduce the issue on reported chrome version 67.0.3396.87 using Windows 10 1803 surface pro, as the issue seems to be fixed in latest canary 69.0.3464.0 providing the bisect info.

Bisect Information:
===================
Last Bad Build  : 69.0.3455.0
First Good Build: 69.0.3456.0 

You are probably looking for a change made after 566097 (known good), but no later than 566108 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/bf52eef6189d519cbb604469a2002cce4e9f6972..c4e0e1ae56a4a7a0dfe7eee8e6a1269f91552822
Suspecting: https://chromium.googlesource.com/chromium/src/+/e6c18518bbcc4fb0ca88aa7d11214021abad09d9
Review URL: https://chromium-review.googlesource.com/946928

@Dave Tapuska: Please help in assigning it to the right owner if this is not related to your change. 
Note: Adding RB-Stable, please remove if not required.

Thanks!

brucedawson@, robliao@

Bruce & Rob do you have an opinion what should be done here? 

Microsoft broke some things with showing the virtual keyboard using the TabTip approach which is fixed by the new code I wrote for InputPane. 

I think the best thing to do is merge the InputPane changes into M68 but there is some associated risk because of the use of the new WinRT API usage so I'm also fine leaving it with the normal release process.

Thanks for the fix.

How serious is this bug? Is there some way to manually invoke the keyboard for password fields or some other way for users to work around this if they don't have access to a physical keyboard? I don't even know what percentage of our customers this applies to.

It seems a bit late to be merging to M68, but "too late" is dependent on severity as well as risk.

Ya you can request the keyboard always by pressing on the icon in the system tray. Appears not to happen on the Window Insider Previews fast channel but does happen in RS4 on another surfacebook.

I believe the right call here is to wait for 69 to progress through the channels then. Targeting 69.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-67; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-67 label, otherwise remove Merge-TBD label. Thanks.

This issue isn't quite fixed in v69.0.3465.  The password field is now acting like a on/off toggle instead of always forcing it to show.  For example, if you click in a regular text field, like a username field, the keyboard appears.  Then, if you click in the password field, the keyboard toggles off.  So, you have to click again in the same password field to make the keyboard show again, then, if you click a third time in the password field, the keyboard toggles back off, etc.  This does not happen in the regular text fields, only in the password fields.  And sometimes/randomly when the keyboard is showing from clicking in the password field, it stops the X in the upper-right corner from closing the program.  When the program does close, the keyboard remains on-screen even though it should disappear.

So, yes, it is usable now, but it's strange and quirky.

If this doesn't need a merge to M68, pls remove "Merge-TBD" label.

Verified the fix on Windows-10 Surface Pro using Chrome version #69.0.3480.0 as per the comment #0.
Attaching screen cast for reference.
Observed that we are to see on-screen keyboard for password entry.
Hence, the fix is working as expected. 
Adding the verified labels.
Note: Able to reproduce the issue on chrome version 67.0.3396.87

Thanks...!!

Deleted: 853403.mp4 996 KB

	853403.mp4 996 KB View Download

Hi all,
This is now happening on C70 for all input fields when the app is run in fullscreen os kiosk mode.
Is there any way to check this please?
It's only since updating to Windows 10 1803 has the keyboard stopped working.
It's the same on C69 and C70.

Thanks,

Hi All,
Windows 10 build 1803 On screen Keyboard issue still persists with new version of google chrome. If we click on the Text field or password field, OSK is not popping up but we need to click on the address bar once to trigger the keyboard. once its triggered it will work in all the Text field and password field. If we close the browser then we need to repeat the same step.

Tried version Google_Chrome_(64bit)_v69.0.3497.81 and found this is the only working version and its very old. With thsi version we are not able to do UTM tracking using Google Analytics. UTM tracking is only working with the latest version of google chrome.

The OSK is working properly in all other browsers except chrome. we cannot escalate this to Microsoft because the problem is only with the chrome version.

Any help will be appreciated.

Thanks...

Hi all,

I can reproduce the behaviour mentioned in chrome 70 kiosk mode with Windows 10 1803 and 1809. It's impossible to use chrome in kiosk mode on touch devices. All the other browsers are working well.

Please provide some support or workaround.

Thank you very much.

same with me, I have three Surface:

1. Company Surface Pro 2017 with Chrome 70.0.3538.110 running on Windows 10 Enterprise 1709, the onscreen keyboard is popping up if I touch a text field, it is working normal.

but on my private devices I have big issues, I tried all mods but nothing is working:

2. a Surface 3 where the windows version is 1809 and the same Chrome version, the on screen keyboard is not popping up if I touch a text field

3. a brand new Surface 6 Pro with Windows 10 1803 and Chrome 70m the onscreen keyboard is not popping up

so it should be a issue linked to the April update... but it is really ugly... pls try to provide a solution

this issue is still not fixed. Even with version 70 of chrome.