Thanks for the report and sorry for the trouble!  In  issue 468806  we "fixed" mouse support in Chrome Android to behave more like a mouse, but didn't consider this scenario.  I suspect we broke this then.

I think ideally showing the OSK on Android would occur whenever an input field is focused and there is no physical keyboard attached.  But I'm not sure if we have this "is a physical keyboard attached" signal today.

The OSK used to be controlled completely outside blink somewhere, but then we did add a hook into Element::focus so that JS focusing an input field could show the keyboard.  Perhaps there's a cleanup opportunity here whereby the OSK showing can ALWAYS be triggered by blink focusing code (and it's only the responsibility of the higher level code to decide if an OSK is enabled or not)?

There doesn't exist a "is a physical keyboard attached" signal on Android, to my knowledge.  We've had that discussion before (although I don't remember exactly on which bug).

I've been thinking of a mouse being currently used as a reasonable-ish proxy for a physical keyboard also being attached.  It's very undesirable for the OSK to show up when a mouse+physical keyboard combo is being used, so this is better than the other naive alternative of always showing the OSK on every focus.

Another idea is to treat a physical keystroke having been seen in the past as a signal, but aside from the detection being late and detach not being observable, soft keyboards do send artificial physical key events and I don't know of a way to distinguish them, so this doesn't seem like a sane path to go down.

Looks like Chrome for Windows is struggling with the same problem space in http://crbug.com/497381 ,   http://crbug.com/335735  , http://crbug.com/491516

> There doesn't exist a "is a physical keyboard attached" signal on Android, to my knowledge.

Err, stackoverflow tells me there is such a method: https://stackoverflow.com/questions/6654177/is-there-a-way-in-android-to-tell-if-a-users-device-has-an-actual-keyboard-or-no .  We can try that and see if it works properly.

Thank you for your quick and comprehensive response. At least, it explains where the problem comes from. However, in my opinion, I would leave the decision wether not to show the OSK to the OS Android, because the OS has more information about the hardware. Showing the OSK when a input field is focussed (even with attached mouse) is the standard behavior in Android and diverting from that is inconsistant and confusing.

In doubt, I would always vote for showing the OSK instead hiding it. I can fully understand that for user with mouse and hardware keyboard, the OSK is annoying, since it takes space from the viewport. However, for disabled users who only can use the mouse (and these are many, because many AT interfaces build on emulating a mouse), not showing the OSK renders Chrome unuseable. 

Furthermore, Chrome on Android cannot simply be replaced with another browser, since WebView also depends on it and therefor also many other apps in the Android ecosystem, including important system apps. So, it's a huge accessibility issue.

aelias@ do you have someone on your team that should investigate this or do you want input-dev to do it?

Issue 735754 has been merged into this issue.

@amaralp, we understand that it is currently holiday, but it would be great if we could receive an update on this issue when you have the change.
If any additional information is needed from us, please let us know.

@amaralp, please let us know if there are any updates for us on this issue.
Thank you!

@amaralp, please let us know if there are any updates for us on this issue.
Thank you!

jaehun.rhee@, sorry for the late response. I've been on vacation for the past week. I'm currently working on this.

Thank you for the update and please keep us posted.
Also, am I able to be added to the CC list for this bug?

You should be added to the CC list. I have a CL being reviewed at https://chromium-review.googlesource.com/c/566279.

Thank you!

FYI, thank you for the quick support as this is currently an approval blocker from our internal QA team for our next flagship device.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c045864eb64f387e5abca941d6a161a5a759a804

commit c045864eb64f387e5abca941d6a161a5a759a804
Author: Pedro Amaral <amaralp@google.com>
Date: Thu Jul 13 17:49:16 2017

Mouse click should trigger virtual keyboard on Android

Have Android also trigger virtual keyboard on mouse up.

Bug:  730038 
Change-Id: Ife9979b96f7e21577ed94af65323d4ac45513c88
Reviewed-on: https://chromium-review.googlesource.com/566279
Commit-Queue: Pedro Amaral <amaralp@chromium.org>
Reviewed-by: Alexandre Elias <aelias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#486435}
[modify] https://crrev.com/c045864eb64f387e5abca941d6a161a5a759a804/content/renderer/input/render_widget_input_handler.cc

Requesting merge to M60.

Severity: High (cannot type) for certain scenarios (accessibility control simulating mouse, Samsung DEX without physical keyboard)
Number of users affected: Very low
Confidence in safety of fix: High
Other factors: Reported as internal QA approval blocker for a device by Samsung.  Regression starting in 58.

This bug requires manual review: We are only 11 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

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

@aelias, are we able to know if the change is merged to M61?

M61 is not branched yet, so because this change is landed on trunk, it will enter M61 without needing merge.

Thank you for the confirmation

Approved for M60 branch 3112.  Please process merge ASAP.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/76190c35f907b98cb342da6775cdbb1026bb3df7

commit 76190c35f907b98cb342da6775cdbb1026bb3df7
Author: Pedro Amaral <amaralp@chromium.org>
Date: Fri Jul 14 23:55:09 2017

Mouse click should trigger virtual keyboard on Android

Have Android also trigger virtual keyboard on mouse up.

TBR=amaralp@google.com

(cherry picked from commit c045864eb64f387e5abca941d6a161a5a759a804)

Bug:  730038 
Change-Id: Ife9979b96f7e21577ed94af65323d4ac45513c88
Reviewed-on: https://chromium-review.googlesource.com/566279
Commit-Queue: Pedro Amaral <amaralp@chromium.org>
Reviewed-by: Alexandre Elias <aelias@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#486435}
Reviewed-on: https://chromium-review.googlesource.com/572520
Reviewed-by: Pedro Amaral <amaralp@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#613}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/76190c35f907b98cb342da6775cdbb1026bb3df7/content/renderer/input/render_widget_input_handler.cc

on the mouse click I do see virtual keyboard on Samsung S8 with Dex mode and without / using 60.0.3112.70 

Note that as of Android O, it appears that Android suppresses the OSK when a physical keyboard is attached at the system level: see observations in  http://crbug.com/750787  .  Therefore Chromium now has the ideal behavior and no further action is needed.