Fix vietnamese layout to correctly handle cmd + 1.

In vietnamese layout, cmd + [vkeycode=18] does not print any characters. This
should still be correctly interpretted as a hotkey for cmd + '1'.

Previously, the logic for cr_firesForKeyEvent would early exit when
charactersIgnoringModifiers had 0 length. Subsequent logic would use characters
in place of charactersIgnoringModifiers. This CL moves the latter logic before
the former logic so that if charactersIgnoringModifiers has 0 length, we'll
instead check characters.

Change-Id: I3fcc45579c7697ca843ef3472fa294fa2da02262
Bug: 889424
Reviewed-on: https://chromium-review.googlesource.com/1259342
Commit-Queue: Erik Chen <erikchen@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596298}

chrome/browser/ui/cocoa/nsmenuitem_additions.mm

@@ -86,6 +86,23 @@ void SetIsInputSourceCzechForTesting(bool is_czech) {
   NSUInteger eventModifiers =
       [event modifierFlags] & NSDeviceIndependentModifierFlagsMask;
 
+  // cmd-opt-a gives some weird char as characters and "a" as
+  // charactersWithoutModifiers with an US layout, but an "a" as characters and
+  // a weird char as "charactersWithoutModifiers" with a cyrillic layout. Oh,
+  // Cocoa! Instead of getting the current layout from Text Input Services,
+  // and then requesting the kTISPropertyUnicodeKeyLayoutData and looking in
+  // there, let's try a pragmatic hack.
+  if ([eventString length] == 0 ||
+      ([eventString characterAtIndex:0] > 0x7f &&
+       [[event characters] length] > 0 &&
+       [[event characters] characterAtIndex:0] <= 0x7f)) {
+    eventString = [event characters];
+
+    // Process the shift if necessary.
+    if (eventModifiers & NSShiftKeyMask)
+      eventString = [eventString uppercaseString];
+  }
+
   if ([eventString length] == 0 || [[self keyEquivalent] length] == 0)
     return NO;
 
@@ -118,22 +135,6 @@ void SetIsInputSourceCzechForTesting(bool is_czech) {
     eventModifiers |= NSFunctionKeyMask;
   }
 
-  // cmd-opt-a gives some weird char as characters and "a" as
-  // charactersWithoutModifiers with an US layout, but an "a" as characters and
-  // a weird char as "charactersWithoutModifiers" with a cyrillic layout. Oh,
-  // Cocoa! Instead of getting the current layout from Text Input Services,
-  // and then requesting the kTISPropertyUnicodeKeyLayoutData and looking in
-  // there, let's try a pragmatic hack.
-  if ([eventString characterAtIndex:0] > 0x7f &&
-      [[event characters] length] > 0 &&
-      [[event characters] characterAtIndex:0] <= 0x7f) {
-    eventString = [event characters];
-
-    // Process the shift if necessary.
-    if (eventModifiers & NSShiftKeyMask)
-      eventString = [eventString uppercaseString];
-  }
-
   // We intentionally leak this object.
   static __attribute__((unused)) KeyboardInputSourceListener* listener =
       [[KeyboardInputSourceListener alloc] init];

chrome/browser/ui/cocoa/nsmenuitem_additions_unittest.mm

@@ -342,6 +342,15 @@ TEST(NSMenuItemAdditionsTest, TestFiresForKeyEvent) {
   SetIsInputSourceCzechForTesting(false);
   ExpectKeyDoesntFireItem(key, MenuItem(@"1", NSCommandKeyMask),
                           /*compareCocoa=*/false);
+
+  // On Vietnamese layout, cmd + '' [vkeycode = 18] should instead trigger cmd +
+  // '1'. Ditto for other number keys.
+  key = KeyEvent(0x100108, @"1", @"", 18);
+  ExpectKeyFiresItem(key, MenuItem(@"1", NSCommandKeyMask),
+                     /*compareCocoa=*/false);
+  key = KeyEvent(0x100108, @"4", @"", 21);
+  ExpectKeyFiresItem(key, MenuItem(@"4", NSCommandKeyMask),
+                     /*compareCocoa=*/false);
 }
 
 NSString* keyCodeToCharacter(NSUInteger keyCode,