Overhaul WebView IME test

Overhaul WebView IME test

There are some problems with existing WebView IME test.

First off, the example is misleading. Creating a selection range in
JavaScript is not straightforward and is not representative of what
WebView developers should be doing. Focusing on editor is a better use
case.

Also, it was flaky in some old device that we deprecated. As found in
crbug.com/621049, we actually need to wait for document focus before
we can focus on content-editable body.

The reason is that Android's view focus gets propagated to the renderer
process as input message while JavaScript execution gets propagated to
the renderer process as frame message, so JavaScript may be executed
before document gets focused, and focusing on content-editable body
is an invalid operation when document isn't yet focused. I suspect that
this is the reason why some OEM email client was using selection range
trick in the first place.

Finally, we were testing against real input method, which can be another
cause of flakiness, so it's fixed by a fake input method manager.

BUG=621049, 611928
Committed: https://crrev.com/5a6c5bf0a4a00be9743eb3ba171cd5cbab6bd9a1
Cr-Commit-Position: refs/heads/master@{#408291}

[Changwan Ryu, 2016-07-25 09:20:53]

The CQ bit was checked by changwan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-25 09:21:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Changwan Ryu, 2016-07-25 09:21:58]

changwan@chromium.org changed reviewers:
+ aelias@chromium.org

[commit-bot: I haz the power, 2016-07-25 09:47:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-25 09:47:19]

Dry run: This issue passed the CQ dry run.

[aelias_OOO_until_Jul13, 2016-07-25 22:14:06]

lgtm

[Changwan Ryu, 2016-07-25 23:45:22]

changwan@chromium.org changed reviewers:
+ sgurun@chromium.org

[Changwan Ryu, 2016-07-25 23:45:22]

sgurun@, could you take a look?

[sgurun-gerrit only, 2016-07-27 17:50:01]

On 2016/07/25 23:45:22, Changwan Ryu wrote:
> sgurun@, could you take a look?

lgtm

[Changwan Ryu, 2016-07-27 23:44:22]

The CQ bit was checked by changwan@chromium.org

[commit-bot: I haz the power, 2016-07-27 23:44:50]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 00:23:06]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-07-28 00:25:36]

Description was changed from

==========
Overhaul WebView IME test

There are some problems with existing WebView IME test.

First off, the example is misleading. Creating a selection range in
JavaScript is not straightforward and is not representative of what
WebView developers should be doing. Focusing on editor is a better use
case.

Also, it was flaky in some old device that we deprecated. As found in
crbug.com/621049, we actually need to wait for document focus before
we can focus on content-editable body.

The reason is that Android's view focus gets propagated to the renderer
process as input message while JavaScript execution gets propagated to
the renderer process as frame message, so JavaScript may be executed
before document gets focused, and focusing on content-editable body
is an invalid operation when document isn't yet focused. I suspect that
this is the reason why some OEM email client was using selection range
trick in the first place.

Finally, we were testing against real input method, which can be another
cause of flakiness, so it's fixed by a fake input method manager.

BUG=621049, 611928
==========

to

==========
Overhaul WebView IME test

There are some problems with existing WebView IME test.

First off, the example is misleading. Creating a selection range in
JavaScript is not straightforward and is not representative of what
WebView developers should be doing. Focusing on editor is a better use
case.

Also, it was flaky in some old device that we deprecated. As found in
crbug.com/621049, we actually need to wait for document focus before
we can focus on content-editable body.

The reason is that Android's view focus gets propagated to the renderer
process as input message while JavaScript execution gets propagated to
the renderer process as frame message, so JavaScript may be executed
before document gets focused, and focusing on content-editable body
is an invalid operation when document isn't yet focused. I suspect that
this is the reason why some OEM email client was using selection range
trick in the first place.

Finally, we were testing against real input method, which can be another
cause of flakiness, so it's fixed by a fake input method manager.

BUG=621049, 611928

Committed: https://crrev.com/5a6c5bf0a4a00be9743eb3ba171cd5cbab6bd9a1
Cr-Commit-Position: refs/heads/master@{#408291}
==========

[commit-bot: I haz the power, 2016-07-28 00:25:37]

Patchset 1 (id:??) landed as
https://crrev.com/5a6c5bf0a4a00be9743eb3ba171cd5cbab6bd9a1
Cr-Commit-Position: refs/heads/master@{#408291}