chrome/test/data/chromeos/virtual_keyboard/inputs.html - Issue 2771793002: End to end test: async focus shouldn't trigger virtual keyboard.

Side by Side Diff: chrome/test/data/chromeos/virtual_keyboard/inputs.html

Issue 2771793002: End to end test: async focus shouldn't trigger virtual keyboard. (Closed)

Patch Set: . Created 3 years, 9 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

OLD	NEW
1 <!DOCTYPE html>	1 <!DOCTYPE html>

2 <html>	2 <html>

3 <head>	3 <head>

4 <meta charset="utf-8">	4 <meta charset="utf-8">

5 <meta name="viewport" content="width-device-width">	5 <meta name="viewport" content="width-device-width">

6 <title>Virtual Keyboard test page</title>	6 <title>Virtual Keyboard test page</title>

	7 <script>

	8 function syncFocus() {

	9 var input = document.getElementById('text');

	10 input.blur();

	11 input.focus();

	12 }

	13 function asyncFocus() {

	14 var input = document.getElementById('text');

	15 // Keyboard hiding is dalayed by 100 ms, so here we

	16 // wait 200 ms to make sure virtual keyboard is hidden.
	oshima 2017/03/27 16:57:54 it's not clear why we need this. Shouldn't keyboar it's not clear why we need this. Shouldn't keyboard already be hidden? oka 2017/03/28 11:13:26 Unfortunately no. The task to hide keyboard is del Show quoted text On 2017/03/27 16:57:54, oshima wrote: > it's not clear why we need this. Shouldn't keyboard already be hidden? Unfortunately no. The task to hide keyboard is delayed to avoid flickering when focus is moved from a text input to another text input. In this case text input type = NONE is sent to the keyboard controller once. If there is no delay, keyboard controller would close the keyboard for NONE and then reopens it. To avoid this, keyboard controller delays closing and cancels closing if a input element gets focus within 100 ms. Updated the test comment. oshima 2017/03/28 12:00:25 Whey it reopens it? Shouldn't it stay hidden becau Show quoted text On 2017/03/28 11:13:26, oka wrote: > On 2017/03/27 16:57:54, oshima wrote: > > it's not clear why we need this. Shouldn't keyboard already be hidden? > > Unfortunately no. The task to hide keyboard is delayed to avoid flickering when > focus is moved from a text input to another text input. In this case text input > type = NONE is sent to the keyboard controller once. If there is no delay, > keyboard controller would close the keyboard for NONE and then reopens it. To > avoid this, keyboard controller delays closing and cancels closing if a input > element gets focus within 100 ms. Whey it reopens it? Shouldn't it stay hidden because setting focus async won't open keyboard? It looks odd if html code has to wait in order to avoid showing keyboard. Show quoted text > Updated the test comment. oka 2017/03/28 12:50:03 Sorry to make confusion, but in the previous comme Show quoted text On 2017/03/28 12:00:25, oshima wrote: > On 2017/03/28 11:13:26, oka wrote: > > On 2017/03/27 16:57:54, oshima wrote: > > > it's not clear why we need this. Shouldn't keyboard already be hidden? > > > > Unfortunately no. The task to hide keyboard is delayed to avoid flickering > when > > focus is moved from a text input to another text input. In this case text > input > > type = NONE is sent to the keyboard controller once. If there is no delay, > > keyboard controller would close the keyboard for NONE and then reopens it. To > > avoid this, keyboard controller delays closing and cancels closing if a input > > element gets focus within 100 ms. > > Whey it reopens it? Shouldn't it stay hidden because setting focus async won't > open keyboard? > > It looks odd if html code has to wait in order to avoid showing keyboard. > > > Updated the test comment. > Sorry to make confusion, but in the previous comment "If there is no delay, keyboard controller would close the keyboard for NONE and then reopens it." the delay means the 100 ms of delay keyboard controller has. There are three states in virtual keyboard; shown, willHidden and hidden. Once NONE is received, keyboard moves to willHidden state and then it moves to hidden state after 100ms. If some text input element has focus before that keyboard moves to shown state. This is for preventing flickering. By this reason, if the keyboard is opening and then 'async' is clicked, keyboard will not be hidden otherwise the delay of 200ms is specified. If the keyboard is not opening when user clicks 'async', then the keyboard will not be shown even if there is no delay specified in setTimeout. That said, I agree that the test looks strange. Current test checks clicking 'async' hides opening keyboard, but it requires to add 200 ms of delay. Maybe we should change the strategy to check clicking async keeps keyboard closing. It will work if 200 is replaced with 0. Question for this approach is how to ckeck the keyboard is "still hidden". keyboard::WaitUntilHidden can't be used since there is not state change. We need a way to wait until input.focus() is called in the javascript side for the test to be meaningful.
	17 setTimeout(function(){input.focus();}, 200);

	18 }

	19 </script>

7 </head>	20 </head>

8 <body>	21 <body>

9 <p>	22 <p>

10 <label id="blur">blur</label>	23 <label id="blur">blur</label>

11 <input id="text" type="text" placeholder="type=text"></input>	24 <input id="text" type="text" placeholder="type=text"></input>

	25 <!-- test for crbug.com/642513 -->

	26 <button id="sync" onclick="syncFocus()">sync</button>

	27 <button id="async" onclick="asyncFocus()">async</button>

12 </p>	28 </p>

13 </body>	29 </body>

14 </html>	30 </html>

OLD	NEW

« chrome/browser/ui/ash/keyboard_end_to_end_browsertest.cc ('K') | « chrome/browser/ui/ash/keyboard_end_to_end_browsertest.cc ('k') | no next file » | no next file with comments »