[DomKey X11] Produce correct DomKey when Control is down

[DomKey X11] Produce correct DomKey when Control is down

According spec the DomKey for ctrl-<key> should be the same as
pressing <key> along.
(When ctrl-<key> doesn't natively generates printable characters)

The same applies to ctrl-shift-<key>.
(e.g. should produce the same DomKey as shift-<key>)

This CL fixed the issue by removing ctrl modifier from |XKeyEvent|
when querying |KeySym| using |XLookupString()|.
  * We have to do this because we have no way to know whether a key
    combination would print something on screen (see Example 1 below);
  * We can do this because according to XKB map no key combinations
    with ctrl key are mapped to printable characters.

Example 1:
On Linux US keyboard with French layout, |XLookupString()|
  * Returns '?' for ctrl-shift-/
  * Returns '§' for shift-/
We have no way to know if '?' is the character we want.

Spec:
https://github.com/w3c/uievents/issues/113

TEST=Manually
Test 1:
  1. Go to https://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html
  2. Switch to Right Handed Dvorak layout (with en-US physical keyboard)
  3. Press ctrl-'w' (The key labeled as 'w')
  4. 'key' should be '6'

Test 2:
  1. Similar to Test 1, but hit ctrl-shift-'w' in step 3
  2. 'key' should be '^'

Test 3:
  1. Go to https://cdn.rawgit.com/w3c/uievents/gh-pages/tests/key-mtest-102fr-fr.html
  2. Switch to French layout (with en-US physical keyboard)
  3. Click "Show Options" and check "Shift+Control"
  4. Click "Start Test"
  5. Press ctrl-shift-<highlighted keys> one by one, press ESC to skip
     special hotkeys
  6. Most test cases should be green (Expected keys that doesn't exist)

BUG=633838
Committed: https://crrev.com/d093f7b054b78f6740e4aa96e163ae0383ee3cca
Cr-Commit-Position: refs/heads/master@{#431674}

[chongz, 2016-11-03 15:39:00]

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

[commit-bot: I haz the power, 2016-11-03 15:39:37]

Dry run: 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-11-03 16:50:03]

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

[commit-bot: I haz the power, 2016-11-03 16:50:04]

Dry run: This issue passed the CQ dry run.

[chongz, 2016-11-07 21:00:39]

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

[commit-bot: I haz the power, 2016-11-07 21:01:14]

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

[chongz, 2016-11-07 21:06:30]

Patchset #1 (id:1) has been deleted

[chongz, 2016-11-07 21:21:04]

Description was changed from

==========
[DomKey X11] Don't fallback to US layout when Control key is down

BUG=633838
==========

to

==========
[DomKey X11] Produce correct DomKey when Control is down

According spec the DomKey for ctrl-<key> should be the same as
presseing <key> along (When ctrl-<key> doesn't natively generates
printable characters).

The same applies to ctrl-shift-<key>. (e.g. should produce the same
DomKey as shift-<key>)

This CL fixed the issue by removing ctrl modifier from |XKeyEvent|
when querying |KeySym| using |XLookupString()|. 
  * We have to do this because we have no way to know whether a key
    combination would print something on screen (see Example 1 below);
  * We can do this because according to XKB map no key combinations
    with ctrl key are mapped to printable characters.

Example 1:
On Linux US keyboard with French layout, |XLookupString()|
  * Returns '?' for ctrl-shift-/
  * Returns '§' for shift-/
We have no way to know if '?' is the character we want.

Spec:
https://github.com/w3c/uievents/issues/113

BUG=633838
==========

[chongz, 2016-11-07 21:30:37]

Description was changed from

==========
[DomKey X11] Produce correct DomKey when Control is down

According spec the DomKey for ctrl-<key> should be the same as
presseing <key> along (When ctrl-<key> doesn't natively generates
printable characters).

The same applies to ctrl-shift-<key>. (e.g. should produce the same
DomKey as shift-<key>)

This CL fixed the issue by removing ctrl modifier from |XKeyEvent|
when querying |KeySym| using |XLookupString()|. 
  * We have to do this because we have no way to know whether a key
    combination would print something on screen (see Example 1 below);
  * We can do this because according to XKB map no key combinations
    with ctrl key are mapped to printable characters.

Example 1:
On Linux US keyboard with French layout, |XLookupString()|
  * Returns '?' for ctrl-shift-/
  * Returns '§' for shift-/
We have no way to know if '?' is the character we want.

Spec:
https://github.com/w3c/uievents/issues/113

BUG=633838
==========

to

==========
[DomKey X11] Produce correct DomKey when Control is down

According spec the DomKey for ctrl-<key> should be the same as
pressing <key> along.
(When ctrl-<key> doesn't natively generates printable characters)

The same applies to ctrl-shift-<key>.
(e.g. should produce the same DomKey as shift-<key>)

This CL fixed the issue by removing ctrl modifier from |XKeyEvent|
when querying |KeySym| using |XLookupString()|. 
  * We have to do this because we have no way to know whether a key
    combination would print something on screen (see Example 1 below);
  * We can do this because according to XKB map no key combinations
    with ctrl key are mapped to printable characters.

Example 1:
On Linux US keyboard with French layout, |XLookupString()|
  * Returns '?' for ctrl-shift-/
  * Returns '§' for shift-/
We have no way to know if '?' is the character we want.

Spec:
https://github.com/w3c/uievents/issues/113

TEST=Manually
Test 1:
  1. Go to
https://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html
  2. Switch to Right Handed Dvorak layout (with en-US physical keyboard)
  3. Press ctrl-'w' (The key labeled as 'w')
  4. 'key' should be '6'

Test 2:
  1. Similar to Test 1, but hit ctrl-shift-'w' in step 3
  2. 'key' should be '^'

Test 3:
  1. Go to
https://cdn.rawgit.com/w3c/uievents/gh-pages/tests/key-mtest-102fr-fr.html
  2. Switch to French layout (with en-US physical keyboard)
  3. Click "Show Options" and check "Shift+Control"
  4. Click "Start Test"
  5. Press ctrl-shift-<highlighted keys> one by one, press ESC to skip
     special hotkeys
  6. Most test cases should be green (Expected keys that doesn't exist)

BUG=633838
==========

[chongz, 2016-11-07 21:34:35]

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

[chongz, 2016-11-07 21:34:36]

kpschoedel@ I've fixed the issue as you suggested, PTAL, thanks!

[kpschoedel, 2016-11-07 21:41:07]

On 2016/11/07 21:34:36, chongz wrote:
> kpschoedel@ I've fixed the issue as you suggested, PTAL, thanks!

LGTM for ui/events/ changes.

[chongz, 2016-11-07 21:51:27]

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

[chongz, 2016-11-07 21:51:27]

dtapuska@ PTAL, thanks!

[dtapuska, 2016-11-07 22:01:48]

On 2016/11/07 21:51:27, chongz wrote:
> dtapuska@ PTAL, thanks!

lgtm % nit.

Are you writing the manual web platform test for this? It can land independently
since we have no way of actually simulating the native keyboards events.

[dtapuska, 2016-11-07 22:04:37]

https://codereview.chromium.org/2474083002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/editing/EditingBehavior.cpp (right):

https://codereview.chromium.org/2474083002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/EditingBehavior.cpp:282: // According to
XKB map no keyboard combinations with ctrl key are mapped to
Can we move this to be above the !OS(WIN) and change the if OS(WIN) to be #elif?

[chongz, 2016-11-07 22:25:43]

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

[commit-bot: I haz the power, 2016-11-07 22:25:58]

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

[chongz, 2016-11-07 22:43:26]

On 2016/11/07 22:01:48, dtapuska wrote:
> On 2016/11/07 21:51:27, chongz wrote:
> > dtapuska@ PTAL, thanks!
> 
> lgtm % nit.
> 
> Are you writing the manual web platform test for this? It can land
independently
> since we have no way of actually simulating the native keyboards events.

Actually garykac@ has already written manual web platform tests in
https://github.com/w3c/web-platform-tests/tree/master/uievents/keyboard
which is essentially the manual tests mentioned in CL description.

Or do you want me to write tests for Dvorak keyboard? Actually I believe
the issue has the same root cause as French layout, which was discovered before
crbug.com/585241 but left as future improvments.

[chongz, 2016-11-07 22:44:34]

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

[chongz, 2016-11-07 22:44:35]

rbyers@ PTAL, thanks!

https://codereview.chromium.org/2474083002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/editing/EditingBehavior.cpp (right):

https://codereview.chromium.org/2474083002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/EditingBehavior.cpp:282: // According to
XKB map no keyboard combinations with ctrl key are mapped to
On 2016/11/07 22:04:37, dtapuska wrote:
> Can we move this to be above the !OS(WIN) and change the if OS(WIN) to be
#elif?

Done.

[commit-bot: I haz the power, 2016-11-08 01:50:58]

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

[commit-bot: I haz the power, 2016-11-08 01:50:59]

Dry run: This issue passed the CQ dry run.

[chongz, 2016-11-09 15:32:38]

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

[chongz, 2016-11-09 15:32:39]

avi@ PTAL, thanks! (Rick is in Dev Summit)

[Avi (use Gerrit), 2016-11-09 15:36:01]

lgtm

I'll stamp

[chongz, 2016-11-09 15:58:55]

chongz@chromium.org changed reviewers:
- rbyers@chromium.org

[chongz, 2016-11-09 16:06:12]

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

[chongz, 2016-11-09 16:06:12]

cbiesinger@ PTAL at "third_party/WebKit/Source/core/", thanks!

[chongz, 2016-11-10 17:14:50]

chongz@chromium.org changed reviewers:
+ yosin@chromium.org
- cbiesinger@chromium.org

[chongz, 2016-11-10 17:14:51]

yosin@ PTAL at "third_party/WebKit/Source/core/", thanks!

[yosin_UTC9, 2016-11-11 01:49:26]

lgtm for core/editing

https://codereview.chromium.org/2474083002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/editing/EditingBehavior.cpp (right):

https://codereview.chromium.org/2474083002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/EditingBehavior.cpp:274: if
(event.ctrlKey())
Q: How about other modifier keys, Alt, Meta, Hyper, etc?

[chongz, 2016-11-11 20:12:28]

https://codereview.chromium.org/2474083002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/editing/EditingBehavior.cpp (right):

https://codereview.chromium.org/2474083002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/editing/EditingBehavior.cpp:274: if
(event.ctrlKey())
On 2016/11/11 01:49:26, Yosi_UTC9 wrote:
> Q: How about other modifier keys, Alt, Meta, Hyper, etc?

Good question!
  1. Alt: We set |webkit_event.isSystemKey = true| when Alt is down, so it
should never go into here.
    * See "web_input_event.cc::MakeWebKeyboardEventFromUiEvent()"
  2. Meta, Hyper: From my testing these keys don't affect the produced character
on native apps (such as gedit) , otherwise we can fix it later if we found
exceptions.

[chongz, 2016-11-11 21:16:11]

The CQ bit was checked by chongz@chromium.org

[chongz, 2016-11-11 21:16:11]

The patchset sent to the CQ was uploaded after l-g-t-m from
dtapuska@chromium.org, kpschoedel@chromium.org
Link to the patchset: https://codereview.chromium.org/2474083002/#ps40001
(title: "dtapuska's review: Move #if block")

[commit-bot: I haz the power, 2016-11-11 21:16:32]

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-11-11 23:05:49]

Description was changed from

==========
[DomKey X11] Produce correct DomKey when Control is down

According spec the DomKey for ctrl-<key> should be the same as
pressing <key> along.
(When ctrl-<key> doesn't natively generates printable characters)

The same applies to ctrl-shift-<key>.
(e.g. should produce the same DomKey as shift-<key>)

This CL fixed the issue by removing ctrl modifier from |XKeyEvent|
when querying |KeySym| using |XLookupString()|. 
  * We have to do this because we have no way to know whether a key
    combination would print something on screen (see Example 1 below);
  * We can do this because according to XKB map no key combinations
    with ctrl key are mapped to printable characters.

Example 1:
On Linux US keyboard with French layout, |XLookupString()|
  * Returns '?' for ctrl-shift-/
  * Returns '§' for shift-/
We have no way to know if '?' is the character we want.

Spec:
https://github.com/w3c/uievents/issues/113

TEST=Manually
Test 1:
  1. Go to
https://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html
  2. Switch to Right Handed Dvorak layout (with en-US physical keyboard)
  3. Press ctrl-'w' (The key labeled as 'w')
  4. 'key' should be '6'

Test 2:
  1. Similar to Test 1, but hit ctrl-shift-'w' in step 3
  2. 'key' should be '^'

Test 3:
  1. Go to
https://cdn.rawgit.com/w3c/uievents/gh-pages/tests/key-mtest-102fr-fr.html
  2. Switch to French layout (with en-US physical keyboard)
  3. Click "Show Options" and check "Shift+Control"
  4. Click "Start Test"
  5. Press ctrl-shift-<highlighted keys> one by one, press ESC to skip
     special hotkeys
  6. Most test cases should be green (Expected keys that doesn't exist)

BUG=633838
==========

to

==========
[DomKey X11] Produce correct DomKey when Control is down

According spec the DomKey for ctrl-<key> should be the same as
pressing <key> along.
(When ctrl-<key> doesn't natively generates printable characters)

The same applies to ctrl-shift-<key>.
(e.g. should produce the same DomKey as shift-<key>)

This CL fixed the issue by removing ctrl modifier from |XKeyEvent|
when querying |KeySym| using |XLookupString()|. 
  * We have to do this because we have no way to know whether a key
    combination would print something on screen (see Example 1 below);
  * We can do this because according to XKB map no key combinations
    with ctrl key are mapped to printable characters.

Example 1:
On Linux US keyboard with French layout, |XLookupString()|
  * Returns '?' for ctrl-shift-/
  * Returns '§' for shift-/
We have no way to know if '?' is the character we want.

Spec:
https://github.com/w3c/uievents/issues/113

TEST=Manually
Test 1:
  1. Go to
https://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html
  2. Switch to Right Handed Dvorak layout (with en-US physical keyboard)
  3. Press ctrl-'w' (The key labeled as 'w')
  4. 'key' should be '6'

Test 2:
  1. Similar to Test 1, but hit ctrl-shift-'w' in step 3
  2. 'key' should be '^'

Test 3:
  1. Go to
https://cdn.rawgit.com/w3c/uievents/gh-pages/tests/key-mtest-102fr-fr.html
  2. Switch to French layout (with en-US physical keyboard)
  3. Click "Show Options" and check "Shift+Control"
  4. Click "Start Test"
  5. Press ctrl-shift-<highlighted keys> one by one, press ESC to skip
     special hotkeys
  6. Most test cases should be green (Expected keys that doesn't exist)

BUG=633838
==========

[commit-bot: I haz the power, 2016-11-11 23:05:50]

Committed patchset #2 (id:40001)

[commit-bot: I haz the power, 2016-11-11 23:54:12]

Description was changed from

==========
[DomKey X11] Produce correct DomKey when Control is down

According spec the DomKey for ctrl-<key> should be the same as
pressing <key> along.
(When ctrl-<key> doesn't natively generates printable characters)

The same applies to ctrl-shift-<key>.
(e.g. should produce the same DomKey as shift-<key>)

This CL fixed the issue by removing ctrl modifier from |XKeyEvent|
when querying |KeySym| using |XLookupString()|. 
  * We have to do this because we have no way to know whether a key
    combination would print something on screen (see Example 1 below);
  * We can do this because according to XKB map no key combinations
    with ctrl key are mapped to printable characters.

Example 1:
On Linux US keyboard with French layout, |XLookupString()|
  * Returns '?' for ctrl-shift-/
  * Returns '§' for shift-/
We have no way to know if '?' is the character we want.

Spec:
https://github.com/w3c/uievents/issues/113

TEST=Manually
Test 1:
  1. Go to
https://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html
  2. Switch to Right Handed Dvorak layout (with en-US physical keyboard)
  3. Press ctrl-'w' (The key labeled as 'w')
  4. 'key' should be '6'

Test 2:
  1. Similar to Test 1, but hit ctrl-shift-'w' in step 3
  2. 'key' should be '^'

Test 3:
  1. Go to
https://cdn.rawgit.com/w3c/uievents/gh-pages/tests/key-mtest-102fr-fr.html
  2. Switch to French layout (with en-US physical keyboard)
  3. Click "Show Options" and check "Shift+Control"
  4. Click "Start Test"
  5. Press ctrl-shift-<highlighted keys> one by one, press ESC to skip
     special hotkeys
  6. Most test cases should be green (Expected keys that doesn't exist)

BUG=633838
==========

to

==========
[DomKey X11] Produce correct DomKey when Control is down

According spec the DomKey for ctrl-<key> should be the same as
pressing <key> along.
(When ctrl-<key> doesn't natively generates printable characters)

The same applies to ctrl-shift-<key>.
(e.g. should produce the same DomKey as shift-<key>)

This CL fixed the issue by removing ctrl modifier from |XKeyEvent|
when querying |KeySym| using |XLookupString()|.
  * We have to do this because we have no way to know whether a key
    combination would print something on screen (see Example 1 below);
  * We can do this because according to XKB map no key combinations
    with ctrl key are mapped to printable characters.

Example 1:
On Linux US keyboard with French layout, |XLookupString()|
  * Returns '?' for ctrl-shift-/
  * Returns '§' for shift-/
We have no way to know if '?' is the character we want.

Spec:
https://github.com/w3c/uievents/issues/113

TEST=Manually
Test 1:
  1. Go to
https://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html
  2. Switch to Right Handed Dvorak layout (with en-US physical keyboard)
  3. Press ctrl-'w' (The key labeled as 'w')
  4. 'key' should be '6'

Test 2:
  1. Similar to Test 1, but hit ctrl-shift-'w' in step 3
  2. 'key' should be '^'

Test 3:
  1. Go to
https://cdn.rawgit.com/w3c/uievents/gh-pages/tests/key-mtest-102fr-fr.html
  2. Switch to French layout (with en-US physical keyboard)
  3. Click "Show Options" and check "Shift+Control"
  4. Click "Start Test"
  5. Press ctrl-shift-<highlighted keys> one by one, press ESC to skip
     special hotkeys
  6. Most test cases should be green (Expected keys that doesn't exist)

BUG=633838

Committed: https://crrev.com/d093f7b054b78f6740e4aa96e163ae0383ee3cca
Cr-Commit-Position: refs/heads/master@{#431674}
==========

[commit-bot: I haz the power, 2016-11-11 23:54:13]

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