Able to reproduce the issue on reported chrome version 64.0.3282.140 and latest canary 66.0.3346.0 using Mac 10.13.3 hence providing Bisect Info
This issue is specific to Mac
Bisect Info:
================
Good build: 63.0.3239.0
Bad build: 63.0.3240.0

You are probably looking for a change made after 508800 (known good), but no later than 508801 (first known bad).

https://chromium.googlesource.com/chromium/src/+log/145660d6a05041e0da6a412598a29741b9efe816..1320aeb732124bf2deaaa33502d36b2b68d9ffff

Reviewed-on: https://chromium-review.googlesource.com/716736

@ellyjones: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!

My change is probably to blame for this. I don't think this is Pri-1 though - I'll try to find time for it next week.

The NextAction date has arrived: 2018-02-20

I have scheduled time for this this week.

The NextAction date has arrived: 2018-02-23

Here is what I have learned so far:

1) My change to prioritize user hotkeys did introduce this, because as of that change, if there is a menu binding that is identical to a builtin binding, the menu binding is preferred. This would be fine, except that MenuCommandForKeyEvent() is returning the wrong thing in dvorak-qwerty mode: it's returning the menu binding as though the keymap was still dvorak, even when cmd is held down.

2) I think the reason for that lies in [NSMenuItem cr_firesForKeyEventIfEnabled:], which has a block like this:

  // When both |characters| and |charactersIgnoringModifiers| are ascii, we
  // want to use |characters| if it's a character and
  // |charactersIgnoringModifiers| else (on dvorak, cmd-shift-z should fire
  // "cmd-:" instead of "cmd-;", but on dvorak-qwerty, cmd-shift-z should fire
  // cmd-shift-z instead of cmd-:).
  if ([eventString characterAtIndex:0] <= 0x7f &&
      [[event characters] length] > 0 &&
      [[event characters] characterAtIndex:0] <= 0x7f &&
      isalpha([[event characters] characterAtIndex:0]))
    eventString = [event characters];

Since the key is '}' we slide past the isalpha() check and proceed as though the keymap was normal dvorak. I don't fully understand why the isalpha() check is there, but removing it causes a crash at browser startup (!). Replacing it with isprint() causes the dvorak-qwerty case to work, but breaks the regular qwerty case, which is obviously not good. That leads into...

3) The corresponding NSEvent properties in each mode, for cmd-shift-}:

qwerty: keycode 30, characters "]", charactersIgnoringModifiers "}"
dvorak: keycode 30, characters "=", charactersIgnoringModifiers "+"
dvorak-qwerty-cmd: keycode 30, characters "}", charactersIgnoringModifiers "+"

I'm very surprised that [qwerty characters] is "]" and not "}", especially since in dvorak-qwerty-cmd (which is meant to be qwerty when cmd is held down) it's "}".

So, in summary: I think the fix to this problem will lie in [NSMenuItem cr_firesForKeyEventIfEnabled:], but I don't know yet how to get there. thakis@ wrote a lot of this code - thakis, any ideas?

I wrote that 6 years ago or so -- I haven't seen 6-year-ago thakis in a while I'm afraid :-/ I hope he wrote good tests.

tapted touched this code like 2.5 years ago iirc, maybe he has an idea?

Some of the prePerfromKeyEquivalent logic added in https://chromium-review.googlesource.com/c/chromium/src/+/716736 probably needs to move into ui/base/cocoa/command_dispatcher.mm

command_dispatcher.mm's performKeyEquivalent is what calls prePerfromKeyEquivalent, but it only "bubbles up" to the browser window's performKeyEquivalent if the event is not handled by *any* of pre/default/post at the current level.

Thanks for taking a look at this! Are there any updates? This bug is just killing my productivity :(.

My corp macbook just tried to give me Chrome 69 beta, which broke cmd-shift-[] for tab switching. I use the "normal" dvorak keyboard layout, i.e. the key that generates cmd-shift-] is labeled with "=" and "+".

Switching back to Chrome Stable fixed things, but I'm worried that it only bought me a few days reprieve.

Mac triage: over to erikchen@ for keyboard handling.

We've changed the canonical shortcut for prev/next tab to "ctr + shift + tab" and "ctr + tab". This is to match other macOS applications. If you select the "Window" menu, you'll see the updated shortcuts.

It's still possible to use cmd + shift + "}" on QWERTY keyboards, as we have some secret, never exposed anywhere hotkeys: https://cs.chromium.org/chromium/src/chrome/browser/global_keyboard_shortcuts_mac.mm?type=cs&sq=package:chromium&g=0&l=123

I just checked Safari -- they also have secret, undiscoverable hotkeys. But theirs [at least cmd + shift +"}"] do work with dvorak as well. I guess we should match their behavior.

FWIW cmd+shift+"}" works in Terminal also (with dvorak), so it's not just Safari.

Matching Safari would be amazing - I recognize that dvorak users are a minority here and appreciate your consideration.

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

commit 008ab23a1b001dedc34c213ed56d42d5a7868838
Author: erikchen <erikchen@chromium.org>
Date: Thu Aug 09 02:06:39 2018

macOS: Fix hidden shortcuts to work with dvorak(-QWERTY) keyboards.

Most shortcuts are in the main menu. These work fine with dvorak. For hidden
shortcuts, we were previously checking by keycode rather than keyEquivalent.
This would cause issues with dvorak [and really any non US-QWERTY keyboard
layout].

This CL changes the logic to convert hidden shortcuts to NSMenuItems with a
keyEquivalent, and to use the common logic for NSMenuItem matching. This
allows "cmd + shift + }" and similar shortcuts to work on dvorak.

This CL fixes NSMenuItem matching for Dvorak-QWERTY. Previously we were using
either "characters" or "charactersIgnoringModifiers". Both give the wrong
result. The right thing to do is to take the keycode and convert that into a
keyEquivalent.

This CL fixes the implementation of IsChromeAccelerator, which was incorrectly
creating an NSEvent based on a ui::Accelerator.

Change-Id: I7fe79bc9ba860dc018e8fbfed9836e27fca17f85
Bug:  811921 
Reviewed-on: https://chromium-review.googlesource.com/1167466
Commit-Queue: Erik Chen <erikchen@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581752}
[modify] https://crrev.com/008ab23a1b001dedc34c213ed56d42d5a7868838/chrome/browser/global_keyboard_shortcuts_mac.mm
[modify] https://crrev.com/008ab23a1b001dedc34c213ed56d42d5a7868838/chrome/browser/global_keyboard_shortcuts_mac_unittest.mm
[modify] https://crrev.com/008ab23a1b001dedc34c213ed56d42d5a7868838/chrome/browser/ui/cocoa/accelerator_utils_cocoa.mm
[modify] https://crrev.com/008ab23a1b001dedc34c213ed56d42d5a7868838/chrome/browser/ui/cocoa/nsmenuitem_additions.mm
[modify] https://crrev.com/008ab23a1b001dedc34c213ed56d42d5a7868838/chrome/browser/ui/cocoa/nsmenuitem_additions_unittest.mm

Great to see the CL submitted, thank you for fixing this!!

 Issue 880880  has been merged into this issue.

 Issue 881218  has been merged into this issue.

 Issue 880683  has been merged into this issue.

I'd be wary to merge this to M69 [stable]. While the CL itself is not too complicated, there are a lot of edge cases with hotkey handling, and we may very well make things worse by merging.

 Issue 882219  has been merged into this issue.

 Issue 881692  has been merged into this issue.

Does anyone have a timeline for when this is going to be released to Chrome for Mac? Or is there maybe a pre-release I could download and install?

#25: It looks as though the fix is in 70.0.3518.0 and onwards (i.e., beta channel).

 Issue 884469  has been merged into this issue.

I have downloaded the Beta version. I can confirm that the issue is resolved there! Thank you!

 Issue 889915  has been merged into this issue.

 Issue 889970  has been merged into this issue.