Unable to reproduce the issue on reported chrome version #70.0.3538.67 and latest chrome 72.0.3583.0 using Mac OS 10.13.6 by following below steps.

Steps:
=====
1.Launched chrome.
2.Changed keyboard setting to "Dvorak - Qwerty ⌘".
3.Opened many tabs.
4.Using Control+Shift+Tab from the keyboard, tried shifting the tabs.
5.Observed that "next" tab moves from right to left.

Attached screencast for reference.
@reporter: Could you please review attached screencast and let us know if anything is being missed here. Request you to retry issue on latest chrome #72.0.3583.0 by creating a new person without any apps and extensions installed, reset all flags to default and let us know if the issue still persists.
Thanks.!

Deleted: 896389.mp4 3.0 MB

	896389.mp4 3.0 MB View Download

Hello and thank you for reviewing the bug. In the video you made, I do not believe the keyboard layout was actually changed. It is necessary to use the "input menu" in the menu bar to change from the default. I also note that the macOS version is different.

Here is my screencap on 70.0.3538.67 on 10.11.6: https://youtu.be/5hxt027lFTU

Can you try to repro again? Thank you!

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Mac triage: I can reproduce this locally in 72.0.3584.0 on 10.13.6. Over to erikchen@, the Keyboard Person :) Pri-2 for M72.

Able to reproduce the issue on reported chrome version #70.0.3538.67 and latest chrome #72.0.3588.0 using Mac OS 10.12.6. The following is the bisect information.
Note: The issue is regarding Mac OS only.

Bisect Information:
==============
Good build : 70.0.3517.0
Bad build : 70.0.3518.0

Change Log: https://chromium.googlesource.com/chromium/src/+log/76b1e8939a13e7a1687abc20e8502a7ca806d2ed..008ab23a1b001dedc34c213ed56d42d5a7868838
Reviewed on: https://chromium-review.googlesource.com/1167466

Erik@ : Please help in assigning to appropriate owner if this is not related to your change.
Adding ReleaseBlock-Stable as this is a regression in M-70. Please feel free to remove if not applicable.

Thanks.!

Note to myself and Mac team, since I've been playing whack-a-mole for the last 3 months. We currently are trying to mimic and reproduce Apple's NSEvent <-> NSMenuItem matching logic in cr_firesForKeyEvent.

Theoretically, we could use the private AppKit method: __NSFindMenuItemMatchingCommandKeyEvent to reuse their logic. This would be fragile, as we'd be relying on a dlsym-ed function that isn't a part of the public interface.

For now I'll keep playing whack-a-mole since we seem to be getting close.

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

commit b8c2f02721071231304a4899a4df2f2dee94487e
Author: Erik Chen <erikchen@chromium.org>
Date: Wed Oct 24 21:28:46 2018

Fix ctr+shift+tab on Dvorak-QWERTY.

The keyboard shortcut was behaving incorrectly and triggering the shortcut for
ctr+tab. This was fallout from the change of the menu item to use "ctr+shift+->"
as the key equivalent, and AppKit's funky handling of ctr+shift+tab to create
"end of medium" instead of "horizontal tab".

Bug:  896389 
Change-Id: Iea85c69077874201b6e3608771aa9fcbfa368aef
Reviewed-on: https://chromium-review.googlesource.com/c/1298187
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602459}
[modify] https://crrev.com/b8c2f02721071231304a4899a4df2f2dee94487e/chrome/browser/ui/cocoa/nsmenuitem_additions.mm
[modify] https://crrev.com/b8c2f02721071231304a4899a4df2f2dee94487e/chrome/browser/ui/cocoa/nsmenuitem_additions_unittest.mm

Issue 897728 has been merged into this issue.

Confirmed fixed in 72.0.3592.0, thank you!!

 Issue 906973  has been merged into this issue.

 Issue 918592  has been merged into this issue.