I am experiencing exactly the same behaviour. Click with a mouse once or using the TAB key on the keyboard once, make the OSD Keyboard behave properly afterwards.

Google Chrome: 62.0.3202.74 (Official build) (64bit)
Platform: 9901.54.0 (Official Build) stable-channel guado
Firmware Version Google_Guado.6301.108.4

It use to work fine, according to our customer it did break sometimes in October

One more customer with this issue:

- Chrome OS version. 
61.0.3163.120 

- Devices make/model 
Aopen Chromebase and ChromeBox Commercial 

- Hardware ID:
- Google_Ninja.5216.383.7- Chromeboxes are on Google_Ninja.5216.383.7 
- Chromebases are on Google_Sumo.5216.382.5 

Happened after update to version 61
debug logs:
https://drive.google.com/open?id=1NkxEqOu-nGRZTpzj26Ijqi_C6kX2mo6E

We have another customer reporting this issue in Case: 14061480
Customer shared a few videos and images: 

Images showing the OS version of 2 different devices: https://drive.google.com/open?id=12GZZ1BM2dgIvjpwQgoGtpb2EAz6r6wfm

Video showing the behavior on the OS 60 and OS 63 device (Customer noticed the problem on OS 61 but he updated to 63 as an attempt to solve the issue): 
https://drive.google.com/open?id=12Z_SGgko9glnz5lirB9x1sV_gDnbegoI

This is a video showing a test done on a test App where there is only a field to type and the issue is reproducible in there too: 
https://drive.google.com/open?id=1ds4kJbqWFaR4gHgTdx0kkKd4GhWFl68Y

Hi, this is Pablo Carlier - Partner Engineer helping some partners affected by this defect.

When can we expect information about its resolution? What workaround can we provide so far? - Thanks in advance.

Hello. This morning my device got updated to version 64 (beta channel). However, the issue still persists. I am wondering where will this fix will be into?

Thank you!

@blakeo, can you review this issue? Multiple users experience this issue with M61 and above.

@All - Does the issue repro in user mode (instead of kiosk or public session mode) too? Any examples of Chrome extensions or webpages publicly available to reproduce the issue?

Hi @kotah, I'm not sure whether my extension that I attach is usable. It's a simple chrome app extension where you can load it on the browser. Inside is a simple webview that points to a webpage, that has a textbox in it. If you load this on a touch-based device, I'm pretty sure it would be reproducible. 

The attached file is in the first entry in this ticket. 

Just in case, I tested this with an Aopen Commercial touch-based device. 

@kotah, btw, yes it is reproducible in both user and kiosk mode. 

@kotah, I don't have any customer reports regarding user mode. According to users, the issue happens on cfm/kiosk devices only with no physical keyboard attached so it is hard to tell about user mode for sure. I personally was not able to repro it in neither mode, so it is not 100% reproducible.

@ykrychala, have you tried with the Appspace.crx attached to this ticket?

@kotah, I tested it using a Chromebook flip C100P with Chrome sign builder as kiosk and the website reported to fail is: www.gotimeforce2.com.

I haven't had the chance to test in user mode again but the last time I did it was not reproducible as I had it in laptop mode and the physical keyboard worked. I will test again today using the device in tablet mode with my test user and I will let you know.

@kotah, Had the chance to test it again and I was not able to reproduce it in user mode, tested with the same C100P in tablet mode by going to the URL mentioned above in Chrome browser and I was able to type in the selected fields without doing anything else but tapping on them.

Regarding the workaround, I've seen that if you switch to the full keyboard layout while in kiosk you can enable the text boxes by hitting tab and then type on them.

Thanks

@blakeo, can you review? 

Could this be related to a specific hardware? Both on our side and the customer is using Aopen Commercial Chromebox touch devices. (http://www.aopen.com/eu/shop/products/chromebase-commercial-22). 

It won't happen if a keyboard is plugged in though. That is a workaround for our customer too. But they don't expect to plug in a keyboard on a touch-based device.

Hi guys, 

I've recorded a video on the issue. This is using the app attached btw. This is in version 64, and still reproducible. The issue happens if you don't have the keyboard plugged in before we start the app. 

https://www.dropbox.com/s/cwcb2uuka5dx97d/IMG_0693.MOV?dl=0

Hi all, 
Do we have any updates on this? When can we expect a fix/workaround for this issue?

Thanks

@shubhar, can you help finding the right owner of this bug? This issue has a highly visible impact on kiosk devices (though it occurs in user mode too) with touchscreen, but we haven't had updates for weeks.

Hey guys, 

Any updates on this yet?

RBS to raise visibility.

As this is not a regression and the fix is still being investigated, we'll target the fix for a stable refresh push. I.e. we will not block stable pushes as this is already out, but will push build with fix when ready.

Albert please assign this to the right person, thanks.

Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable?

If a fix is in active development, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sorry for the slow response.
I started to investigate this issue.

Hello @yhanada. If you need help on reproducing this, please let me know. Basically, our clients have been asking for updates on this and we would be glad to assist. Thank you!

Thank you for your help! I can reproduce the issue with the extension attached in comment #1.

As far as I tested, IME receives the collect TextInputType (TEXT_INPUT_TYPE_TEXT), but the textfield seems not to be focused.

Let me add this bug to Blink>Editing>IME component to get some insights from Blink team.

Investigating

The issue seems to be reproducible on Linux by installing the extension and launching Chrome with the "--touch-devices=<mouse_id>" flag (the on-screen keyboard doesn't come up, but the input refuses to focus). Will bisect. 

Bisects to:

commit abbfa348d9f8a3ce2185f4ee678b86b08cf52d4c
Author: Lucas Furukawa Gadani <lfg@chromium.org>
Date:   Tue Aug 29 19:37:57 2017 +0000

    Prevent an inner WebContents from stealing focus from an outer WebContents.
    
    An inner WebContents will only allow itself to be focused in two cases:
      - When the outer WebContents has focus and advances focus to the inner
      WebContents.
      - When an outer WebContents has focus and focus the inner WebContents
      through window.focus() API.
    
    Bug:  725622 
    Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
    Change-Id: If8ef4ed3386eadc2bb22c3afa7701d627c13eb39
    Reviewed-on: https://chromium-review.googlesource.com/636624
    Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
    Reviewed-by: James MacLean <wjmaclean@chromium.org>
    Commit-Queue: Lucas Gadani <lfg@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#498203}

lfg@, is this something we should fix in Chrome, or is there a fix the extension author should apply?

gkihmba@, can you please confirm the priority of this bug (it's currently set as P0) and that we intend to fix it in a stable refresh push? The bug has been present since 61.0.3163.73 (it was originally landed after the branch cut for M61 and then merged to the branch).

Re#34: I'm not sure why Chrome does not treat the touch devices the same way with respect to granting focus to the window as pointer devices. But overall, we don't want the webview renderer process stealing focus from other frames as that can cause other unintended consequences.

I think the app developer will have to fix the issue. Adding the following javascript fixes the issue observed on the app in c#1:

window.onload = function() {
  var webview = document.querySelector('webview');
  webview.addEventListener('loadstop', function() { webview.focus(); });
}

Can the original reporter confirm the workaround works for them?

Tested on our sample app, it can be done. However, we won't be using the loadstop listener but instead touchstart event to prevent it from setting the focus straight away upon load. Still working on it inside our App. Thank you. 

Since the alternative works, I'll close this as WontFix.

This problem went away for us in the latest stable releases for v61 and v62 [62.0.3202.97 (Official Build) (32-bit)]. But after I upgraded our test device to the beta v64 [64.0.3282.41 (Official Build) beta (32-bit)] the problem returned. Can you add the fix to all versions going forward?

The workaround javascript above didn't work for me (or I don't know how to properly implement it). I added it to the top of background_main.js. I use Chrome App Builder Chrome browser Extension to generate our chrome kiosk apps: https://chrome.google.com/webstore/detail/chrome-app-builder/ighkikkfkalojiibipjigpccggljgdff - this app builder creates apps without this workaround.

Please help

Our test machine updated to version 63 on stable channel [63.0.3239.116 (official Build) (32-bit)]. The problem returned to this version as well. So far no problem on the latest releases of v60, v61 and v62 in stable channel, but problems return in stable 63 and beta 64

Hi @bart, and all. 

How we solve it is by putting an invisible div on top of the webview. When the div got 'ontouch', then only we can programmatically set the focus on the webview, at the same time remove the invisible div. We were hoping that if we touch the webview, we will get an 'blur' event on our parent div and set the focus to the webview, but unfortunately, that's not the case.

Hello team,

I have here a customer who is still having issue with this. 

The workaround that was shared here didn't work on their end and they are looking for a fix.

Do we have any update for this?


Thanks in advance!

rarel, try the workaround from this thread: https://bugs.chromium.org/p/chromium/issues/detail?id=799970#c1

It worked for us. Also, if you are using the Kiosk App Generator, the latest version is implementing this fix automatically. 

 Issue 808411  has been merged into this issue.

Hello all,
The same customer of #43 has tried both workaround, but it's still not working for them:
At the first access to the app (which is nothing more than a redirect on a web page) touch screen writing works. 
As the web page is updated, the problem reappears and it is no longer possible to write in the dedicated cells with touch screenwriting.
The only way to make touch screenwriting on the screen work correctly again is to click on a dedicated "force restart session" button.
the app have been created using chrome app builder.
Please advice on how to proceed.

799970 can probably be merged to this thread too

We have already tested the new chrome app builder and also try to add the code snippet to our app but in both cases no work...we need help we have device blocked in public area from october 2017

Re#46: can you share your app and repro steps?

hi lfg@, here is the link with repro steps and application details from #46:
https://drive.google.com/open?id=1KeFGKH_GUY8kOfYjw2Xnw8PHJv0eO_1F9JUptehYwiw

This is another problem with the chrome app builder app, in particular, when clicking the home button the CAB does not restores focus to the webview.

To fix you need to add this.webview.focus() to the onHome function. Probably the remaining functions should be fixed as well.

For this particular issue, where you see:

    {
      name: 'onHome',
      code: function() {
        console.log('navigate to: ' + this.data.homepage);
        this.webview.src = this.data.homepage;
      }
    },

needs to be changed to 

    {
      name: 'onHome',
      code: function() {
        console.log('navigate to: ' + this.data.homepage);
        this.webview.src = this.data.homepage;
        this.webview.focus();
      }
    },


Assigning to Mark to look at this.

The proposed workaround has shipped in Chrome App Builder 1.0.3.

Assigning to Lucas to assess next steps for a fix in Chromium.

As I mentioned before, this change was intentional, we don't want the inner WebContents stealing focus from the outer contents, unless it is explicitly given focus through the focus API.

Now that the CAB issue has been addressed, I'll close this as WontFix again.

Hello, as customer we confirm that the issue now with 1.0.3 is solved.

Thanks