Tagging UI>Input>Text>IME for triage.

Also repro'ed with Chinese Pinyin IME.

tapted@, do you have any ideas?
I'm wondering whether there are changes recently for IMF@Mac?

Btw, this only repros on web input field, not repro on native input field (e.g. omnibox).

Nothing comes to mind - karandeepb@ did some small refactors, but I don't think it affected WebContents in an interesting way.

Bisect'ed:
https://chromium.googlesource.com/chromium/src/+log/c46a4efb3b605ad9197bb08e4eeeb26b095d669d..5332e706dab032f7ca8686880dd1f0f6b31bc91c

Reverting r399369 locally fixes the problem for me.

author	dtapuska <dtapuska@chromium.org>	Sat Jun 11 16:06:19 2016
Handle the "key" field as opposed to keyIdentifier field.

keyIdentifier will be deprecated soon so we need to move over to the
standardized identifier.

Approved Intent to Remove: https://groups.google.com/a/chromium.org/d/msg/blink-dev/fqnFyoDCOaA/s4WIxZPqAAAJ

BUG= 607349 

Review-Url: https://codereview.chromium.org/2045603002
Cr-Commit-Position: refs/heads/master@{#399369}

shuchen@ do you have any ideas? I presume the IME is not consuming the tab as it should be and passing it to the webview which then causes a focus event. Perhaps the IME use to pass the event but it might not have been populated correctly. I'm off today and this weekend for a national holiday but will look at it Monday if you don't have any ideas.

The IME will consume the TAB key. However, before IME consume any keys, the IME will respect that whether the app wants to allow IME to continue processing it.
For example, considering a gaming web app which has a settings UI to allow users to configure the shortcut keys. An input field shows which key is mapped to UP key, and if user presses "W", the input field will show "W", no matter whether there is an IME activated (e.g. Chinese Pinyin IME).
In such web app, it should listen onkeydown and do event.preventDefault() if the keyCode is 229. Therefore, the IME won't work at all.

I'm guessing that when IMF asks that whether Chrome wants to handle the VKEY_PROCESSKEY event (transformed from the TAB key), Chrome processes the TAB key anyway and causes the focus change.

Can your code detect the VKEY code instead of DomKey/DomCode?

FYI. Another similar  issue 622158  may shares the same root cause of this.

The  issue 622158  is for Chrome OS, and I used to apply a workaround but it broke dead key scenario.

It might be will check tomorrow. I think the real fix might be to set a isComposing flag on the input event and not do the default tab action when isComposing is on. 

IsComposing is part of the ui events spec that we haven't implemented yet.  

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

commit febbb09d4df69afde4e6294a842a02e90a9cabdf
Author: dtapuska <dtapuska@chromium.org>
Date: Tue Jul 05 03:58:01 2016

Don't perform the default action when keyCode is 229.

The keyCode of 229 signifies that this event is being dispatched during
an IME composition. Previously keyIdentifier ended up being ProcessKey but
with the converstion to key events this started to be processed.

Put a conditional around the event to ensure that keyCode == 229 events
are discarded. This will eventually be replaced with the isComposing
flag that should be added to KeyboardEvent.

BUG= 620794 ,  622158 

Review-Url: https://codereview.chromium.org/2121843002
Cr-Commit-Position: refs/heads/master@{#403737}

[modify] https://crrev.com/febbb09d4df69afde4e6294a842a02e90a9cabdf/third_party/WebKit/Source/core/input/KeyboardEventManager.cpp

I could verify the fix in 54.0.2789.0 (Mac). Thank you guys :-)

Your change meets the bar and is auto-approved for M53 (branch: 2785)

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

commit be5ae235b1fd6fcbe8bae4500e100ae9eacca8db
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Wed Jul 06 13:36:28 2016

Don't perform the default action when keyCode is 229.

The keyCode of 229 signifies that this event is being dispatched during
an IME composition. Previously keyIdentifier ended up being ProcessKey but
with the converstion to key events this started to be processed.

Put a conditional around the event to ensure that keyCode == 229 events
are discarded. This will eventually be replaced with the isComposing
flag that should be added to KeyboardEvent.

BUG= 620794 ,  622158 

Review-Url: https://codereview.chromium.org/2121843002
Cr-Commit-Position: refs/heads/master@{#403737}
(cherry picked from commit febbb09d4df69afde4e6294a842a02e90a9cabdf)

Review URL: https://codereview.chromium.org/2127843002 .

Cr-Commit-Position: refs/branch-heads/2785@{#26}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/be5ae235b1fd6fcbe8bae4500e100ae9eacca8db/third_party/WebKit/Source/core/input/KeyboardEventManager.cpp

Verified the issue on Mac 10.11.5 using 53.0.2785.8.
dtapuska@ : Could you please review the attached screen cast and let us know if anything is missed here.

Deleted: 622158_July_7.mp4 582 KB

	622158_July_7.mp4 582 KB View Download