New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 617640 link

Starred by 5 users

Issue metadata

Status: Duplicate
Merged: issue 619906
Owner:
Closed: Jun 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug


Show other hotlists

Hotlists containing this issue:
Fixing-touch


Sign in to add a comment

Kiosk Mode and Touch: Subsequent javascript focus to text widget doesn't open keyboard

Reported by aaron.na...@pearson.com, Jun 6 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Platform: 8172.47.0 (Official Build) beta-channel veyron_minnie

Steps to reproduce the problem:
1. Open a webview app in kiosk mode with only touch enabled (Disable the hardware keyboard). The webview needs to go to a document similar to this: 
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <script type="text/javascript" src="../libs/jquery.js"></script>
    <title></title>
</head>
<body>
<button id="clicky">Click to focus</button><br /><br />
<textarea id="texty" style="width: 300px; height: 250px; border: 1px solid black"></textarea>
<script>
    $( "#clicky").on( "click", function(e) {
        $( "#texty").focus();
    })
</script>
</body>
</html>
2. Click on the button. Notice focus goes to the textarea and the software keyboard opens.
3. Dismiss the keyboard.
4. Click on the button again.

What is the expected behavior?
The textarea should get focus and the the software keyboard should open.

What went wrong?
The textarea gets focus, but the software keyboard does not reopen.

Did this work before? N/A 

Chrome version: 51.0.2704 79 beta  Channel: beta
OS Version: 51.0.2704 79 beta
Flash Version: 

In the example I was using a text area, but the same applies to input fields or contenteditables. 

The same app will work as expected if you aren't in kiosk mode. The behavior is the same in the stable channel as the beta channel.
 
Cc: wuyingbing@chromium.org shuchen@chromium.org adlr@chromium.org
Components: -UI UI>Input>Touch
Labels: -Pri-2 ReleaseBlock-Stable M-51 Pri-1
Owner: jen...@chromium.org
Status: Assigned (was: Unconfirmed)
Cc: ekaramad@chromium.org rsa...@chromium.org
If this is already in stable channel on R51 it is too late for it to be a release blocker effectively :(.

Has there been any progress on a fix for this?
We are looking to do another stable release, any idea on the timeline for a fix for this?
Labels: -M-51 M-52
Since we are already in stable, and there has been no activity on this, the chance for getting it in here is very low, so punting it to R52. 
Is this issue seen in M52 or M53?
Mergedinto: 619906
Status: Duplicate (was: Assigned)
I suspect this is a duplicate ... please feel free to undup if I'm wrong ...

Sign in to add a comment