Cannot repro on 10.11. Perhaps 10.12-only?

Can someone try to repro on 10.12?

Unable to reproduce the issue in MacBook Pro (Retina, 15-inch, Mid 2014), 10.12.3 using chrome stable #57.0.2987.133 and latest canary #59.0.3066.0.

Following are the steps followed to reproduce the issue.
------------
1. Switched to US English keyboard in MacOS and was able to switch tabs using cmd+shift+[ or cmd+shift+]
2.  Switched to another language i.e Pinyin Traditional.
3.  Tried to switch tabs using cmd+shift+[ or cmd+shift+] and was able to switch tabs using cmd+shift+[ or cmd+shift+] without any issues.

Attaching screen cast for reference.

shuanwang@ - Could you please check this issue on latest chrome stable #57.0.2987.133 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 708895.mp4 2.6 MB

	708895.mp4 2.6 MB View Download

I was able to reproduce this - macOS 10.12.4 Sierra, Chrome 58.0.3029.81 as well as today's Canary, 60.0.3086.0. (Also switching from US -> Pinyin Traditional.) Not sure what's specific to my/shuanwang's setup that makes this happen though. In case it's relevant, I'm using an external keyboard on a Mac Pro (the cylinder-shaped one)?

[mac bug triage] +wez, can you help triage this bug? CC'ing you from ownership of ui/events/keycodes.

The original report is for Chrome M55, while Chrome stable-channel is already M58, so if this is a Chrome issue then it's not a recent regression.

On my device (Mac OS 10.12.4, Chrome M58 and Chrome M60), I see:

- Cmd+Shift+[ is broken under Pinyin - Traditional.
  If you open a site that listens for keyboard input events and prints them then you'll see something like:

keydown  keyCode=91  ([)   which=91  ([)   charCode=0        
         key=Meta char=undefined location=1 repeat=false
keydown  keyCode=16        which=16        charCode=0        
         key=Shift char=undefined location=1 repeat=false
keydown  keyCode=219       which=219       charCode=0        
         key=「 char=undefined location=0 repeat=false
keyup    keyCode=16        which=16        charCode=0        
         key=Shift char=undefined location=1 repeat=false
keyup    keyCode=91  ([)   which=91  ([)   charCode=0        
         key=Meta char=undefined location=1 repeat=false

  (The third keydown is actually the "[" key; the first and last events are Cmd, which happens to have the same VKEY value as the ASCII for "["...)

- Cmd+Shift+[ works fine under Hirigana _unless you press [ first_.
  Once you press [ you get a keydown with the same |key| value as under the Pinyin layout, which I think affects composition state, the Cmd+Shift+[ shortcut no longer works, though.

So it looks like an interaction between shortcut handling and IME composition?

chongz: Can you take a look?

(Adding IME component tags, and tagging as an issue in M55)

I don't think this is a regression. I did a rough bisect on macOS 10.12.4 and was able to reproduce on M35 (Pinyin - Simplified).

krajshree@ Can you help confirm if this is macOS version related (e.g. 10.12.1, 10.12.3, 10.12.4)? Thanks!


--- Thoughts on the bug itself
On macOS we map shortcuts based on one of [event charactersIgnoringModifiers], [event characters], or [event keyCode], see |global_keyboard_shortcuts_mac.mm::CommandForKeyEvent()|:
https://cs.chromium.org/chromium/src/chrome/browser/global_keyboard_shortcuts_mac.mm?l=123

My debug log shows that on macOS 10.12.4, M60, pressing Command-Shift-[ we get:
* English and Hirigana Layout: (Good)
  * [event charactersIgnoringModifiers] => "{"
  * [event characters] => "["
* Pinyin - Simplified Layout: (Bad)
  * [event charactersIgnoringModifiers] => "「"
  * [event characters] => "{"

Maybe we should use [event characters] if [event charactersIgnoringModifiers] is not ascii?

The NextAction date has arrived: 2017-05-23

Per #c7, krajshree@,
Can you help confirm if this is macOS version related (e.g. 10.12.1, 10.12.3, 10.12.4)?

ekaramad@, Do you have an idea why this happened?

I am not quite sure why. This only happens (for me) for Pinyin IME. I also agree with comment #7. I tired Chromium 15.0.876.0 and the issue reproduces.

I did more digging and agree with findings in comment #7. Alternatively, we could add two new entries to the shortcuts table to account for Pinyin IME and look for VKEY code instead of character. I have put up a demo CL for that here:

https://codereview.chromium.org/2901293004

It works fine on all input methods I tested.

The NextAction date has arrived: 2017-05-30

Remove Blink>Editing>IME
According to the patchin #c14, it can be fixed in browser side changes.

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

commit 90b1637839bc498f3de67b66ca0a4c8e250929fb
Author: ekaramad <ekaramad@chromium.org>
Date: Wed Jun 07 16:04:25 2017

Add virtual key code entry to support Command + Shift + [\] tab switching in some Chinese IME

When using Pinyin-IME, pressing Command + Shift + [ (or ]) does not lead to the
same NSEvent as those of other keyboard types. Therefore, when such IMEs are active
these standard key combinations do not work.

This CL will add two more rows to the list of global Mac shortkeys such that the
command lookup would fall back to the new entries which are based on virtual key
codes.

BUG= 708895 

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

[modify] https://crrev.com/90b1637839bc498f3de67b66ca0a4c8e250929fb/chrome/browser/global_keyboard_shortcuts_cocoa_mac.mm

Following comment #17 and after verifying on todays Canary:
61.0.3124.0 (Official Build) canary (64-bit)
marking this bug as fixed.