Reland: [DomKey] Expose Korean special keys on Korean keyboard layout only

Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}
> Revert: https://codereview.chromium.org/2061123005

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale.
This should be an issue of DrMemory test or Windows itself.
See https://crbug.com/612736#c11

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| returns empty string if the specified locale is invalid. (e.g. Korean HKL without calling 'LoadKeyboardLayout()')

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere and run DrMemory full test, which will fail as well.

BUG=612736
Committed: https://crrev.com/3f4cf0ae18a6792114b1358f7bf56333b041ba27
Cr-Commit-Position: refs/heads/master@{#402611}

[chongz, 2016-06-23 21:24:24]

Description was changed from

==========
Support Korean specific DomKey map

BUG=
==========

to

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}

The issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests on Korean and Japanese locale. (no idea why though)

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

BUG=612736
==========

[chongz, 2016-06-23 21:27:21]

Description was changed from

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}

The issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests on Korean and Japanese locale. (no idea why though)

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

BUG=612736
==========

to

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale. (no idea why though)

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| will fall-back to default locale if the specified
locale is invalid. 

BUG=612736
==========

[chongz, 2016-06-23 21:53:06]

Description was changed from

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale. (no idea why though)

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| will fall-back to default locale if the specified
locale is invalid. 

BUG=612736
==========

to

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale. (no idea why though)

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| will fall-back to default locale if the specified
locale is invalid. 

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test.

BUG=612736
==========

[chongz, 2016-06-24 14:22:41]

Description was changed from

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale. (no idea why though)

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| will fall-back to default locale if the specified
locale is invalid. 

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test.

BUG=612736
==========

to

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale. (no idea why though)

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| will fall-back to default locale if the specified
locale is invalid. 

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test, which will fail as well.

BUG=612736
==========

[chongz, 2016-06-24 14:24:49]

Description was changed from

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale. (no idea why though)

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| will fall-back to default locale if the specified
locale is invalid. 

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test, which will fail as well.

BUG=612736
==========

to

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}
> Revert: https://codereview.chromium.org/2061123005

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale. (no idea why though)

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| will fall-back to default locale if the specified
locale is invalid. 

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test, which will fail as well.

BUG=612736
==========

[chongz, 2016-06-24 14:29:58]

chongz@chromium.org changed reviewers:
+ tommycli@chromium.org

[chongz, 2016-06-24 14:29:59]

tommycli@ PTAL at this CL for re-landing, thanks!

I've tested DrMemory locally, but is there a way to test it on try bots?

[tommycli, 2016-06-24 16:47:55]

Hi chongz: I recommend finding the original reviewer.

I have very little knowledge about the Win32 stuff, and I think the original
reviewer might have better insight.

[chongz, 2016-06-24 17:05:32]

chongz@chromium.org changed reviewers:
+ wez@chromium.org

[chongz, 2016-06-24 17:05:32]

wez@ PTAL at this CL for re-landing, thanks!

Plus: do you know anything about why |LoadKeyboardLayout()| won't pass DrMemory
on Korean&Japan locale?

Fail log can be find here: https://crbug.com/612736#c6

https://codereview.chromium.org/2097643002/diff/20001/ui/events/keycodes/plat...
File ui/events/keycodes/platform_key_map_win_unittest.cc (right):

https://codereview.chromium.org/2097643002/diff/20001/ui/events/keycodes/plat...
ui/events/keycodes/platform_key_map_win_unittest.cc:40: //
|GetInputLocale(L"00000412", KLF_ACTIVATE)| returns the coct
Also tried:
  1. L"0412:E0010412"
  2. L"E0010412"
  3. L"04120412"
  4. L"00010412"
Which returns the default locale and won't pass this unit test. (But will pass
DrMemory test)

1) 2): https://msdn.microsoft.com/en-us/goglobal/bb895996.aspx

[Wez, 2016-06-24 17:54:58]

https://codereview.chromium.org/2097643002/diff/20001/ui/events/keycodes/plat...
File ui/events/keycodes/platform_key_map_win_unittest.cc (right):

https://codereview.chromium.org/2097643002/diff/20001/ui/events/keycodes/plat...
ui/events/keycodes/platform_key_map_win_unittest.cc:40: //
|GetInputLocale(L"00000412", KLF_ACTIVATE)| returns the coct
What is the 'coct Korean locale'?

Do you mean 'LoadKeyboardLayout' rather than 'GetInputLocale'?

As noted on the bug, have you tried passing the fully qualified layout Id to
LoadKeyboardLayout (i.e. E0010412)?

[chongz, 2016-06-24 18:07:27]

https://codereview.chromium.org/2097643002/diff/20001/ui/events/keycodes/plat...
File ui/events/keycodes/platform_key_map_win_unittest.cc (right):

https://codereview.chromium.org/2097643002/diff/20001/ui/events/keycodes/plat...
ui/events/keycodes/platform_key_map_win_unittest.cc:40: //
|GetInputLocale(L"00000412", KLF_ACTIVATE)| returns the coct
On 2016/06/24 17:54:57, Wez wrote:
> What is the 'coct Korean locale'?
> 
> Do you mean 'LoadKeyboardLayout' rather than 'GetInputLocale'?
> 
> As noted on the bug, have you tried passing the fully qualified layout Id to
> LoadKeyboardLayout (i.e. E0010412)?

Sorry for the typo... Yes it should be 'LoadKeyboardLayout()' and 'correct
Korean locale' (i.e. (HKL)0x04120412).

By 'fully qualified layout Id (E0010412)' do you mean 2) mentioned in the first
comment? If so yes I've tried it and it returns default locale. (i.e.
LoadKeyboardLayout(L"E0010412", KLF_ACTIVATE) => (HKL)0x04090409, which is
en-US)

[Wez, 2016-06-24 18:17:19]

On 2016/06/24 18:07:27, chongz wrote:
>
https://codereview.chromium.org/2097643002/diff/20001/ui/events/keycodes/plat...
> File ui/events/keycodes/platform_key_map_win_unittest.cc (right):
> 
>
https://codereview.chromium.org/2097643002/diff/20001/ui/events/keycodes/plat...
> ui/events/keycodes/platform_key_map_win_unittest.cc:40: //
> |GetInputLocale(L"00000412", KLF_ACTIVATE)| returns the coct
> On 2016/06/24 17:54:57, Wez wrote:
> > What is the 'coct Korean locale'?
> > 
> > Do you mean 'LoadKeyboardLayout' rather than 'GetInputLocale'?
> > 
> > As noted on the bug, have you tried passing the fully qualified layout Id to
> > LoadKeyboardLayout (i.e. E0010412)?
> 
> Sorry for the typo... Yes it should be 'LoadKeyboardLayout()' and 'correct
> Korean locale' (i.e. (HKL)0x04120412).
> 
> By 'fully qualified layout Id (E0010412)' do you mean 2) mentioned in the
first
> comment? If so yes I've tried it and it returns default locale. (i.e.
> LoadKeyboardLayout(L"E0010412", KLF_ACTIVATE) => (HKL)0x04090409, which is
> en-US)

Oh, sorry - missed that in your comment.  Huh, that's very strange.

Perhaps Bruce can help give some idea of what is crashing, so we can determine
the most appropriate work-around.

IIUC your patch correctly, it'll fail the tests if the Korean layout isn't
already loaded on the test system, since you're no longer calling
LoadKeyboardLayout()?

[chongz, 2016-06-24 18:43:42]

Description was changed from

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}
> Revert: https://codereview.chromium.org/2061123005

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale. (no idea why though)

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| will fall-back to default locale if the specified
locale is invalid. 

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test, which will fail as well.

BUG=612736
==========

to

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}
> Revert: https://codereview.chromium.org/2061123005

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale. (no idea why though)

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| returns empty string if the specified locale is invalid. (e.g.
Korean HKL without calling 'LoadKeyboardLayout()') 

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test, which will fail as well.

BUG=612736
==========

[chongz, 2016-06-24 18:45:55]

https://codereview.chromium.org/2097643002/diff/20001/ui/events/keycodes/plat...
File ui/events/keycodes/platform_key_map_win_unittest.cc (right):

https://codereview.chromium.org/2097643002/diff/20001/ui/events/keycodes/plat...
ui/events/keycodes/platform_key_map_win_unittest.cc:40: //
|GetInputLocale(L"00000412", KLF_ACTIVATE)| returns the coct
On 2016/06/24 18:07:27, chongz wrote:
> On 2016/06/24 17:54:57, Wez wrote:
> > What is the 'coct Korean locale'?
> > 
> > Do you mean 'LoadKeyboardLayout' rather than 'GetInputLocale'?
> > 
> > As noted on the bug, have you tried passing the fully qualified layout Id to
> > LoadKeyboardLayout (i.e. E0010412)?
> 
> Sorry for the typo... Yes it should be 'LoadKeyboardLayout()' and 'correct
> Korean locale' (i.e. (HKL)0x04120412).
> 
> By 'fully qualified layout Id (E0010412)' do you mean 2) mentioned in the
first
> comment? If so yes I've tried it and it returns default locale. (i.e.
> LoadKeyboardLayout(L"E0010412", KLF_ACTIVATE) => (HKL)0x04090409, which is
> en-US)

> Oh, sorry - missed that in your comment.  Huh, that's very strange.
> 
> Perhaps Bruce can help give some idea of what is crashing, so we can determine
> the most appropriate work-around.

Sure I'll wait for his comments.

> 
> IIUC your patch correctly, it'll fail the tests if the Korean layout isn't
> already loaded on the test system, since you're no longer calling
> LoadKeyboardLayout()?

Actually it won't fail because we are only testing non-printable keys on Korean.
i.e. We check the value of HKL (lowest byte == 0x12 LANG_KOREAN) and do the
mapping VKEY->DomKey.
Note: "ToUnicodeEx(layout)" returns empty string in this case.

However 'LoadKeyboardLayout()' is required for French tests because we need
'ToUnicodeEx(layout)' for printable keys.

[Wez, 2016-06-24 18:48:45]

On 2016/06/24 18:45:55, chongz wrote:
>
https://codereview.chromium.org/2097643002/diff/20001/ui/events/keycodes/plat...
> File ui/events/keycodes/platform_key_map_win_unittest.cc (right):
> 
>
https://codereview.chromium.org/2097643002/diff/20001/ui/events/keycodes/plat...
> ui/events/keycodes/platform_key_map_win_unittest.cc:40: //
> |GetInputLocale(L"00000412", KLF_ACTIVATE)| returns the coct
> On 2016/06/24 18:07:27, chongz wrote:
> > On 2016/06/24 17:54:57, Wez wrote:
> > > What is the 'coct Korean locale'?
> > > 
> > > Do you mean 'LoadKeyboardLayout' rather than 'GetInputLocale'?
> > > 
> > > As noted on the bug, have you tried passing the fully qualified layout Id
to
> > > LoadKeyboardLayout (i.e. E0010412)?
> > 
> > Sorry for the typo... Yes it should be 'LoadKeyboardLayout()' and 'correct
> > Korean locale' (i.e. (HKL)0x04120412).
> > 
> > By 'fully qualified layout Id (E0010412)' do you mean 2) mentioned in the
> first
> > comment? If so yes I've tried it and it returns default locale. (i.e.
> > LoadKeyboardLayout(L"E0010412", KLF_ACTIVATE) => (HKL)0x04090409, which is
> > en-US)
> 
> > Oh, sorry - missed that in your comment.  Huh, that's very strange.
> > 
> > Perhaps Bruce can help give some idea of what is crashing, so we can
determine
> > the most appropriate work-around.
> 
> Sure I'll wait for his comments.
> 
> > 
> > IIUC your patch correctly, it'll fail the tests if the Korean layout isn't
> > already loaded on the test system, since you're no longer calling
> > LoadKeyboardLayout()?
> 
> Actually it won't fail because we are only testing non-printable keys on
Korean.
> i.e. We check the value of HKL (lowest byte == 0x12 LANG_KOREAN) and do the
> mapping VKEY->DomKey.
> Note: "ToUnicodeEx(layout)" returns empty string in this case.
> 
> However 'LoadKeyboardLayout()' is required for French tests because we need
> 'ToUnicodeEx(layout)' for printable keys.

Makes sense.  LGTM as-is in order to get the issue resolved, but let's see what
Bruce says.

[chongz, 2016-06-28 23:54:38]

Description was changed from

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}
> Revert: https://codereview.chromium.org/2061123005

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale. (no idea why though)

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| returns empty string if the specified locale is invalid. (e.g.
Korean HKL without calling 'LoadKeyboardLayout()') 

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test, which will fail as well.

BUG=612736
==========

to

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}
> Revert: https://codereview.chromium.org/2061123005

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale.
This should be an issue of DrMemory test or Windows itself.
See https://crbug.com/612736#c11

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| returns empty string if the specified locale is invalid. (e.g.
Korean HKL without calling 'LoadKeyboardLayout()') 

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test, which will fail as well.

BUG=612736
==========

[chongz, 2016-06-28 23:55:20]

The CQ bit was checked by chongz@chromium.org

[chongz, 2016-06-28 23:55:20]

The patchset sent to the CQ was uploaded after l-g-t-m from wez@chromium.org
Link to the patchset: https://codereview.chromium.org/2097643002/#ps40001
(title: "Rebase")

[commit-bot: I haz the power, 2016-06-28 23:56:36]

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-06-29 00:22:17]

Description was changed from

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}
> Revert: https://codereview.chromium.org/2061123005

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale.
This should be an issue of DrMemory test or Windows itself.
See https://crbug.com/612736#c11

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| returns empty string if the specified locale is invalid. (e.g.
Korean HKL without calling 'LoadKeyboardLayout()') 

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test, which will fail as well.

BUG=612736
==========

to

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}
> Revert: https://codereview.chromium.org/2061123005

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale.
This should be an issue of DrMemory test or Windows itself.
See https://crbug.com/612736#c11

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| returns empty string if the specified locale is invalid. (e.g.
Korean HKL without calling 'LoadKeyboardLayout()') 

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test, which will fail as well.

BUG=612736
==========

[commit-bot: I haz the power, 2016-06-29 00:22:19]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-06-29 00:24:11]

Description was changed from

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}
> Revert: https://codereview.chromium.org/2061123005

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale.
This should be an issue of DrMemory test or Windows itself.
See https://crbug.com/612736#c11

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which 
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| returns empty string if the specified locale is invalid. (e.g.
Korean HKL without calling 'LoadKeyboardLayout()') 

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test, which will fail as well.

BUG=612736
==========

to

==========
Original issue's description:
> [DomKey] Expose Korean special keys on Korean keyboard layout only
>
> Korean keyboard has special keys "HangulMode" and "HanjaMode", we should
> only expose them when the system layout is Korean. Otherwise we should
> return "Unidentified".
>
> This matches Firefox and windows virtual key.
>
> Note: This also works with JIS keyboard + Korean layout, because we are
> mapping DomKey based on KeyboardCode instead of DomCode.
>
> BUG=612736
>
> Committed: https://crrev.com/bdcfb5a1816f1bad537d7611c7ccb972b550339c
> Cr-Commit-Position: refs/heads/master@{#399783}
> Revert: https://codereview.chromium.org/2061123005

Original issue:
Windows API |LoadKeyboardLayout()| won't pass DrMemory
tests for Korean and Japanese locale.
This should be an issue of DrMemory test or Windows itself.
See https://crbug.com/612736#c11

Solution:
Just skip |LoadKeyboardLayout()| and hardcode locale for Korean,
it works because we are only testing non-printable keys, which
doesn't care about |ToUnicodeEx()|.

Note:
|ToUnicodeEx()| returns empty string if the specified locale is invalid. (e.g.
Korean HKL without calling 'LoadKeyboardLayout()')

Also Note:
"mock_keyboard.h" has the similar issue, e.g.
Call "MockKeyboard::GetCharacters(MockKeyboard::LAYOUT_KOREAN, ..)" somewhere
and run DrMemory full test, which will fail as well.

BUG=612736

Committed: https://crrev.com/3f4cf0ae18a6792114b1358f7bf56333b041ba27
Cr-Commit-Position: refs/heads/master@{#402611}
==========

[commit-bot: I haz the power, 2016-06-29 00:24:12]

Patchset 3 (id:??) landed as
https://crrev.com/3f4cf0ae18a6792114b1358f7bf56333b041ba27
Cr-Commit-Position: refs/heads/master@{#402611}