Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1706683002:
[Mac] Produce correct DomKey when Ctrl/Shift/Command is down (Closed)
Description[Mac] Produce correct DomKey when Ctrl/Shift/Command is down
Assume the key combination does not produce a printable character when Ctrl/Command is down.
Use UCKeyTranslate() to get fallback character without modifiers except Shift and Alt.
After CL e.g.
On US keyboard
Ctrl+h == h ==> DomKey 'h'
Ctrl+CapsLock+b == CapsLock+b ==> 'B'
Ctrl+Alt+g == Alt+g ==> '∂'
Ctrl+Alt+Shift+d == Alt+Shift+d ==> 'Î'
French Keyboard
Ctrl+Shift+2 == Shift+2 ==> '2'
Ctrl+2 == 2 ==> 'é'
This will match Chrome's behavior on other platforms and mostly match Firefox's behavior.
(FF has some issue with Ctrl+2 on French keyboard)
BUG=586571
Committed: https://crrev.com/ca9e1ec794ea4da8248fb40695d0a8b70f4e8085
Cr-Commit-Position: refs/heads/master@{#377346}
Patch Set 1 #Patch Set 2 : Use std::iscntrl to check control characters instead of writing own method #
Total comments: 1
Patch Set 3 : Add test case for Ctrl+Shift+foo #
Total comments: 1
Patch Set 4 : Use Shift, Alt and CapsLock as fallback modifiers #
Total comments: 3
Patch Set 5 : Fix Ctrl/Ctrl+Shift to pass garykac's keyboard tester #
Total comments: 20
Patch Set 6 : tapted's review, add test Alt and Ctrl Alt #
Total comments: 5
Patch Set 7 : dtapuska and tdresser's review #
Messages
Total messages: 32 (14 generated)
chongz@chromium.org changed reviewers: + dtapuska@chromium.org
Hi dtapuska, can you take a look at the CL please? Thanks!
https://codereview.chromium.org/1706683002/diff/20001/content/browser/rendere... File content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm (right): https://codereview.chromium.org/1706683002/diff/20001/content/browser/rendere... content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:269: } table[] = {{kVK_ANSI_A, 'a', ui::DomKey::FromCharacter('a')}, We likely should add a test case with Shift set.
Description was changed from ========== Ctrl+a..z should produce a..z as DomKey on Mac Use NSEvent::charactersIgnoringModifiers if it's a key combination and NSEvent::characters belongs to Ascii control characters. BUG=586571 ========== to ========== Ctrl+a..z should produce a..z as DomKey on Mac instead of Ascii control characters. Use NSEvent::charactersIgnoringModifiers if it's a key combination and NSEvent::characters belongs to Ascii control characters. This will match Firefox's behavior. BUG=586571 ==========
Description was changed from ========== Ctrl+a..z should produce a..z as DomKey on Mac instead of Ascii control characters. Use NSEvent::charactersIgnoringModifiers if it's a key combination and NSEvent::characters belongs to Ascii control characters. This will match Firefox's behavior. BUG=586571 ========== to ========== Ctrl+a..z should produce a..z as DomKey on Mac instead of Ascii control characters. Use NSEvent::charactersIgnoringModifiers if it's a key combination and NSEvent::characters belongs to Ascii control characters. This will match Firefox's behavior and Chrome's behavior on other platforms. BUG=586571 ==========
chongz@chromium.org changed reviewers: + garykac@chromium.org
Hi garykac, can you take a look at this CL please? Thanks! https://codereview.chromium.org/1706683002/diff/40001/ui/events/keycodes/keyb... File ui/events/keycodes/keyboard_code_conversion_mac.mm (right): https://codereview.chromium.org/1706683002/diff/40001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_mac.mm:751: [characters characterAtIndex:[characters length] - 1]; Use last character because e.g. On French keyboard [+a will produce "^q", DomKey should be 'q'.
On 2016/02/17 22:54:05, chongz wrote: > Hi garykac, can you take a look at this CL please? Thanks! > > https://codereview.chromium.org/1706683002/diff/40001/ui/events/keycodes/keyb... > File ui/events/keycodes/keyboard_code_conversion_mac.mm (right): > > https://codereview.chromium.org/1706683002/diff/40001/ui/events/keycodes/keyb... > ui/events/keycodes/keyboard_code_conversion_mac.mm:751: [characters > characterAtIndex:[characters length] - 1]; > Use last character because e.g. On French keyboard [+a will produce "^q", DomKey > should be 'q'. How does this handle French [Digit2] and [Shift + Digit2]? The first produces 'é', while the second produces '2. Note: if the current spec ("character without modifiers") is technically challenging to implement, we can consider changing it to be the character without ctrl or alt (or "character without non-shift modifiers"), but we have to be careful about the AltGr modifier. Let me know if you'd like me to have that discussion with other browser vendors.
Hi garykac, I've updated CL so it will use Shift, Alt and CapsLock as fallback
modifiers. (To match Firefox)
e.g.
US keyboard:
Alt+g == Ctrl+Alt+g ==> '∂'
Alt+Shift+d == Ctrl+Alt+Shift+d ==> 'Î'
French keyboard:
Shift+2 == Ctrl+Shift+2 ==> '2'
2 ==> 'é' but Ctrl+2 ==> '2' (don't know why but matches Firefox)
https://codereview.chromium.org/1706683002/diff/60001/ui/events/keycodes/keyb...
File ui/events/keycodes/keyboard_code_conversion_mac.mm (right):
https://codereview.chromium.org/1706683002/diff/60001/ui/events/keycodes/keyb...
ui/events/keycodes/keyboard_code_conversion_mac.mm:806: unichar dom_key_char =
French [Digit2] and [Shift + Digit2] will both produce a printable character, so
DomKey will be the correct character.
https://codereview.chromium.org/1706683002/diff/60001/ui/events/keycodes/keyb...
ui/events/keycodes/keyboard_code_conversion_mac.mm:815: NSShiftKeyMask |
NSAlphaShiftKeyMask | NSAlternateKeyMask;
Use custom fallback modifiers here since NSEvent::charactersIgnoringModifiers
only cares about Shift.
Should I add NSAlphaShiftKeyMask (CapsLock) here to match Firefox?
https://codereview.chromium.org/1706683002/diff/60001/ui/events/keycodes/keyb...
ui/events/keycodes/keyboard_code_conversion_mac.mm:817: dom_key_char =
KeycodeAndModifiersToCharacter(
In this stage we don't care about dead keys any more.
Description was changed from
==========
Ctrl+a..z should produce a..z as DomKey on Mac instead of Ascii control
characters.
Use NSEvent::charactersIgnoringModifiers if it's a key combination and
NSEvent::characters belongs to Ascii control characters.
This will match Firefox's behavior and Chrome's behavior on other platforms.
BUG=586571
==========
to
==========
Use fallback DomKey when key combination doesn't produce printable character on
Mac.
If NSEvent::characters is Ascii control characters(considered as non-printable),
clear modifierFlags except Shift, CapsLock and AltGr and use UCKeyTranslate() to
get fallback character.
e.g.
On US keyboard
Ctrl+h ==> h ==> 'h'
Ctrl+CapsLock+b ==> CapsLock+b ==> 'B'
Ctrl+Alt+g ==> Alt+g ==> '∂'
Ctrl+Alt+Shift+d ==> Alt+Shift+d ==> 'Î'
French Keyboard
Ctrl+Shift+2 == Shift+2 ==> '2'
2 ==> 'é' but Ctrl+2 ==> '2' (don't know why but matches Firefox)
This will match Firefox's behavior and Chrome's behavior on other platforms.
BUG=586571
==========
On 2016/02/18 06:04:08, chongz wrote: > Hi garykac, I've updated CL so it will use Shift, Alt and CapsLock as fallback > modifiers. (To match Firefox) > > e.g. > US keyboard: > Alt+g == Ctrl+Alt+g ==> '∂' > Alt+Shift+d == Ctrl+Alt+Shift+d ==> 'Î' > French keyboard: > Shift+2 == Ctrl+Shift+2 ==> '2' > 2 ==> 'é' but Ctrl+2 ==> '2' (don't know why but matches Firefox) I think that's a bug in FF -- they don't consistently use the shifted or unshifted value. I updated my manual keyboard tester to include expected values for Ctrl and Shift+Ctrl. These tests are linked from the UIEvents github page (https://github.com/w3c/uievents), but here are the direct links: 101en-us: https://cdn.rawgit.com/w3c/uievents/gh-pages/tests/key-mtest-101en-us.html 102fr-fr: https://cdn.rawgit.com/w3c/uievents/gh-pages/tests/key-mtest-102fr-fr.html Open "Options", select "Control" or "Shift+Control", press the "Start Test" button and then the highlighted keys. Note that Chrome steals a lot of Ctrl+key combos, so the test might be easier to run on a Mac. You can use Escape to skip over any keys during the test. Let me know if any of these test values seem incorrect to you. I'll be following up with FF to talk about the cases where they deviate from what we expect. Overall the cl LGTM, but please verify the |key| values with the tests.
Description was changed from
==========
Use fallback DomKey when key combination doesn't produce printable character on
Mac.
If NSEvent::characters is Ascii control characters(considered as non-printable),
clear modifierFlags except Shift, CapsLock and AltGr and use UCKeyTranslate() to
get fallback character.
e.g.
On US keyboard
Ctrl+h ==> h ==> 'h'
Ctrl+CapsLock+b ==> CapsLock+b ==> 'B'
Ctrl+Alt+g ==> Alt+g ==> '∂'
Ctrl+Alt+Shift+d ==> Alt+Shift+d ==> 'Î'
French Keyboard
Ctrl+Shift+2 == Shift+2 ==> '2'
2 ==> 'é' but Ctrl+2 ==> '2' (don't know why but matches Firefox)
This will match Firefox's behavior and Chrome's behavior on other platforms.
BUG=586571
==========
to
==========
[Mac] Produce correct DomKey when Ctrl/Shift/Command is down
Assume the key combination does not produce a printable character when
Ctrl/Command is down.
Use UCKeyTranslate() to get fallback character without modifiers except Shift
and Alt.
After CL e.g.
On US keyboard
Ctrl+h == h ==> DomKey 'h'
Ctrl+CapsLock+b == CapsLock+b ==> 'B'
Ctrl+Alt+g == Alt+g ==> '∂'
Ctrl+Alt+Shift+d == Alt+Shift+d ==> 'Î'
French Keyboard
Ctrl+Shift+2 == Shift+2 ==> '2'
Ctrl+2 == 2 ==> 'é'
This will match Chrome's behavior on other platforms and mostly match Firefox's
behavior.
(FF has some issue with Ctrl+2 on French keyboard)
BUG=586571
==========
Patchset #5 (id:80001) has been deleted
chongz@chromium.org changed reviewers: + thakis@chromium.org
Hi thakis, can you take a look at this CL please? I'm not sure if it's the right way to check if a keydown will produce a character in the input field. Thanks! https://codereview.chromium.org/1706683002/diff/100001/content/browser/render... File content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm (right): https://codereview.chromium.org/1706683002/diff/100001/content/browser/render... content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:265: if (![CurrentKeyboardLayoutName() isEqualToString:@"U.S."]) This test case won't work on other keyboard layout like French layout. Is there a better way to do the check? https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... File ui/events/keycodes/keyboard_code_conversion_mac.mm (right): https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:807: if (dom_key_char < 0x80 && ([event modifierFlags] & kCtrlCmdKeyMask)) { I'm trying to match the logic here https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit... So basically I want to know if this keydown will produce a character in the input field.
thakis@chromium.org changed reviewers: + tapted@chromium.org
I haven't looked at the keyboard handling code in years. tapted, didn't you touch this a few months ago?
On 2016/02/23 17:31:34, Nico wrote: > I haven't looked at the keyboard handling code in years. tapted, didn't you > touch this a few months ago? I poked around a bit to fix a test a while ago... It looks like dtapuska@ has been more active here recently, so I'll defer to them for the unicode/mapping stuff and the DomKeyFromCharCode changes. I did a pass over the code, but you'll still need a ui/ OWNER . I'd wait for dtapuska's lg too. https://codereview.chromium.org/1706683002/diff/100001/content/browser/render... File content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm (right): https://codereview.chromium.org/1706683002/diff/100001/content/browser/render... content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:67: TISInputSourceRef source = TISCopyCurrentKeyboardInputSource(); it looks like this `Copy` is leaked https://codereview.chromium.org/1706683002/diff/100001/content/browser/render... content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:69: [NSString stringWithFormat:@"%@", TISGetInputSourceProperty( optional: it looks like TISGetInputSourceProperty returns a CFStringRef, so you could probably do ScopedCFTypeRef<TISInputSourceRef> source( TISCopyCurrentKeyboardInputSource()); CFStringRef layout = static_cast<CFStringRef>(TISGetInputSourceProperty( source, kTISPropertyLocalizedName)); return [[base::mac::CFToNSCast(layout) retain] autorelease]; or even call this method IsUSKeyboardLayout() and adjust https://codereview.chromium.org/1706683002/diff/100001/content/browser/render... content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:122: // Additional tests for US layout nit: full stop after comments -- more below https://codereview.chromium.org/1706683002/diff/100001/content/browser/render... content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:265: if (![CurrentKeyboardLayoutName() isEqualToString:@"U.S."]) On 2016/02/22 20:17:18, chongz wrote: > This test case won't work on other keyboard layout like French layout. Is there > a better way to do the check? I think it would be better simply to fail the test if the layout isn't US. All the bots should have a US layout, and we need to detect if that ever changes or, say, Apple decides to change the formatting of the localized name. https://codereview.chromium.org/1706683002/diff/100001/content/browser/render... content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:286: for (size_t i = 0; i < arraysize(table); ++i) { I think `for (const DomKeyTestCase& entry : table)` works now too. Also below. https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... File ui/events/keycodes/keyboard_code_conversion_mac.mm (right): https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:637: bool& is_deadkey) { bool& -> bool* (non-const refs aren't allowed in Chromium). But also I don't think you need the is_deadkey argument at all (see below) https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:640: int native_modifiersers = 0; modifiersers ? "native" is a bit confusing too since `NSShiftKeyMask` is native too. Perhaps unicode_modifiers? https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:645: if (modifiers & NSControlKeyMask) aren't some of these effectively deadcode since you pass ` modifiers & (NSShiftKeyMask | NSAlphaShiftKeyMask | NSAlternateKeyMask)`. https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:655: CFDataRef layout_data = static_cast<CFDataRef>(TISGetInputSourceProperty( Since it's used a couple of times (and layout_data isn't otherwise needed) const UCKeyboardLayout* layout = reinterpret_cast<..>(... ) https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:669: if (status == noErr && char_count == 0) *is_deadkey = status == noErr && char_count == 0; But also is there any time the result should be other that noErr? The UCKeyTranslate documentation suggests to me it would only give an error if the input is garbage (e.g. layout_data is null) So perhaps OSSTATUS_DCHECK(status == noErr, status); *is_deadkey = char_count == 0; [edit] But, then you don't really seem to need is_deadkey as an out param, so you can just do if (char_count == 0) { // Inject space... https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:675: // Inject space to get character value of dead key. I don't really understand what this means https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:676: UCKeyTranslate(reinterpret_cast<const UCKeyboardLayout*>( Assign result and do OSSTATUS_DCHECK(status == noErr, status); https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:805: // On Mac Blink won't insert ASCII character if Ctrl/Command is down. `Ctrl/Command is` -> `either Ctrl or Command, or both, are down` https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:806: // See EditingBehavior::shouldInsertCharacter() full stop after comment https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:813: const int fallback_modifiers = kFallbackModifiers or perhaps kAllowedModifiersMask? https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:818: is_deadkey); is_deadkey isn't used after this - remove?
https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... File ui/events/keycodes/keyboard_code_conversion_mac.mm (right): https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:807: if (dom_key_char < 0x80 && ([event modifierFlags] & kCtrlCmdKeyMask)) { On 2016/02/22 20:17:18, chongz wrote: > I'm trying to match the logic here > https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit... > > So basically I want to know if this keydown will produce a character in the > input field. Also I'm not sure what you're asking here. If you asking whether native NSTextFields insert a character if either Cmd or Ctrl are down (or both), then the answer is "no". (But they do if Alt is pressed). However, Ctrl on Mac triggers a lot of text-editing commands that can still change the input field. E.g. Ctlr+T will swap characters either side of the cursor.
chongz@chromium.org changed reviewers: + tdresser@chromium.org
Thanks for the detailed review! I've updated CL as per your comments. Hi dtapuska@, can you take a look at the CL again please? Hi tdresser@, can I have a review on the renderer_host/input please? Thanks! https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... File ui/events/keycodes/keyboard_code_conversion_mac.mm (right): https://codereview.chromium.org/1706683002/diff/100001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:807: if (dom_key_char < 0x80 && ([event modifierFlags] & kCtrlCmdKeyMask)) { On 2016/02/24 00:05:51, tapted wrote: > On 2016/02/22 20:17:18, chongz wrote: > > I'm trying to match the logic here > > > https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit... > > > > So basically I want to know if this keydown will produce a character in the > > input field. > > Also I'm not sure what you're asking here. If you asking whether native > NSTextFields insert a character if either Cmd or Ctrl are down (or both), then > the answer is "no". (But they do if Alt is pressed). > > However, Ctrl on Mac triggers a lot of text-editing commands that can still > change the input field. E.g. Ctlr+T will swap characters either side of the > cursor. Yes that's exactly what I need, thanks! https://codereview.chromium.org/1706683002/diff/120001/ui/events/keycodes/key... File ui/events/keycodes/keyboard_code_conversion_mac.mm (right): https://codereview.chromium.org/1706683002/diff/120001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:636: UniChar MacKeycodeAndModifiersToCharacter(unsigned short mac_keycode, Use mac_keycode instead of native_key_code to match existing code for consistency. https://codereview.chromium.org/1706683002/diff/120001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:678: return unicode_string[0]; Haven't find a case yet.
https://codereview.chromium.org/1706683002/diff/120001/ui/events/keycodes/key... File ui/events/keycodes/keyboard_code_conversion_mac.mm (right): https://codereview.chromium.org/1706683002/diff/120001/ui/events/keycodes/key... ui/events/keycodes/keyboard_code_conversion_mac.mm:662: UniChar unicode_string[255]; Why is this 255? when your max string length passed into UCKeyTranslate method is size 1. Perhaps that is why you haven't found a case yet?
Other than a couple periods (there's a few more missing in that file), this LGTM, but I'm no keyboard expert, so wait for an LGTM from dtapuska as well. https://codereview.chromium.org/1706683002/diff/120001/content/browser/render... File content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm (right): https://codereview.chromium.org/1706683002/diff/120001/content/browser/render... content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:275: // Tests ctrl_dom_key Add period. https://codereview.chromium.org/1706683002/diff/120001/content/browser/render... content/browser/renderer_host/input/web_input_event_builders_mac_unittest.mm:280: // Tests ctrl_shift_dom_key period
Hi dtapuska, sorry that was a typo, I've updated CL, please take a look, thanks!
On 2016/02/24 18:04:15, chongz wrote: > Hi dtapuska, sorry that was a typo, I've updated CL, please take a look, thanks! lgtm
The CQ bit was checked by chongz@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from garykac@chromium.org, tdresser@chromium.org Link to the patchset: https://codereview.chromium.org/1706683002/#ps140001 (title: "dtapuska and tdresser's review")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1706683002/140001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1706683002/140001
Message was sent while issue was closed.
Description was changed from
==========
[Mac] Produce correct DomKey when Ctrl/Shift/Command is down
Assume the key combination does not produce a printable character when
Ctrl/Command is down.
Use UCKeyTranslate() to get fallback character without modifiers except Shift
and Alt.
After CL e.g.
On US keyboard
Ctrl+h == h ==> DomKey 'h'
Ctrl+CapsLock+b == CapsLock+b ==> 'B'
Ctrl+Alt+g == Alt+g ==> '∂'
Ctrl+Alt+Shift+d == Alt+Shift+d ==> 'Î'
French Keyboard
Ctrl+Shift+2 == Shift+2 ==> '2'
Ctrl+2 == 2 ==> 'é'
This will match Chrome's behavior on other platforms and mostly match Firefox's
behavior.
(FF has some issue with Ctrl+2 on French keyboard)
BUG=586571
==========
to
==========
[Mac] Produce correct DomKey when Ctrl/Shift/Command is down
Assume the key combination does not produce a printable character when
Ctrl/Command is down.
Use UCKeyTranslate() to get fallback character without modifiers except Shift
and Alt.
After CL e.g.
On US keyboard
Ctrl+h == h ==> DomKey 'h'
Ctrl+CapsLock+b == CapsLock+b ==> 'B'
Ctrl+Alt+g == Alt+g ==> '∂'
Ctrl+Alt+Shift+d == Alt+Shift+d ==> 'Î'
French Keyboard
Ctrl+Shift+2 == Shift+2 ==> '2'
Ctrl+2 == 2 ==> 'é'
This will match Chrome's behavior on other platforms and mostly match Firefox's
behavior.
(FF has some issue with Ctrl+2 on French keyboard)
BUG=586571
==========
Message was sent while issue was closed.
Committed patchset #7 (id:140001)
Message was sent while issue was closed.
Description was changed from
==========
[Mac] Produce correct DomKey when Ctrl/Shift/Command is down
Assume the key combination does not produce a printable character when
Ctrl/Command is down.
Use UCKeyTranslate() to get fallback character without modifiers except Shift
and Alt.
After CL e.g.
On US keyboard
Ctrl+h == h ==> DomKey 'h'
Ctrl+CapsLock+b == CapsLock+b ==> 'B'
Ctrl+Alt+g == Alt+g ==> '∂'
Ctrl+Alt+Shift+d == Alt+Shift+d ==> 'Î'
French Keyboard
Ctrl+Shift+2 == Shift+2 ==> '2'
Ctrl+2 == 2 ==> 'é'
This will match Chrome's behavior on other platforms and mostly match Firefox's
behavior.
(FF has some issue with Ctrl+2 on French keyboard)
BUG=586571
==========
to
==========
[Mac] Produce correct DomKey when Ctrl/Shift/Command is down
Assume the key combination does not produce a printable character when
Ctrl/Command is down.
Use UCKeyTranslate() to get fallback character without modifiers except Shift
and Alt.
After CL e.g.
On US keyboard
Ctrl+h == h ==> DomKey 'h'
Ctrl+CapsLock+b == CapsLock+b ==> 'B'
Ctrl+Alt+g == Alt+g ==> '∂'
Ctrl+Alt+Shift+d == Alt+Shift+d ==> 'Î'
French Keyboard
Ctrl+Shift+2 == Shift+2 ==> '2'
Ctrl+2 == 2 ==> 'é'
This will match Chrome's behavior on other platforms and mostly match Firefox's
behavior.
(FF has some issue with Ctrl+2 on French keyboard)
BUG=586571
Committed: https://crrev.com/ca9e1ec794ea4da8248fb40695d0a8b70f4e8085
Cr-Commit-Position: refs/heads/master@{#377346}
==========
Message was sent while issue was closed.
Patchset 7 (id:??) landed as https://crrev.com/ca9e1ec794ea4da8248fb40695d0a8b70f4e8085 Cr-Commit-Position: refs/heads/master@{#377346} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
