Can not reproduce it. Can you please attach a screencast of the issue? Thanks in advance.

Attached cmd-shift-t.mov

This is with all extensions off.

Final "blank" tab appears when I press cmd+shift+t

I have just discovered that this is when using the "Dvorak-Qwerty [CMD symbol]" input source, and I've confirmed that the shortcut does indeed work when I switch to "U.S" layout. So maybe it's somehow an OS bug? But it did definitely work with the previous version of Chrome and the Dvorak/Qwerty layout.

Thanks.

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

The screencast file is too big to attach, but hopefully the above comment will help you reproduce it.

Hi, all. I think I have a similar problem.

More specifically, in non-English input(in my case, Korean), shift modifier seems to be dropped when pressing shortcuts.

e.g. press: cmd + shift + t(restore tab) -> result: New tab opens(cmd + t)
     press: cmd + shift + n(open incognito) -> result: Normal window opens(cmd + n)

steven@, is this same with your problem?

steven.m.oneill@ Thanks for the issue...

This issue working fine in latest beta 70.0.3538.35 and seems to be fixed in Issue:   811921  , hence merging into it and marking it as Duplicate.
Note: Feel free to Un-dupe it if not the case. Removing Needs-Bisect label to it.

@Reporter: Could you please check this 70.0.3538.35(M-70 Moving to stable in two to three weeks), you can download latest chrome builds here:" https://www.chromium.org/getting-involved/dev-channel ".

Thanks.!

Hi phanindra.mandapaka@

I tested again with Canary, but still happens. Sometimes it works as expected. But After switching input language several times, it happens again.

@sangowoo108 -- yes same behavior for me with cmd+shift+N

steven@ thank you for confirmmation.

erik@ could you take a look at this or help us triage/assign this, please?

Three questions:

1) Which Korean IME are you using?
2) Does this issue reproduce in Safari?

> sometimes it works as expected. But After switching input language several times, it happens again.

3) Please clarify -- does it always work when you launch Chrome, and IME is set to korean? Or is it sometimes broken even without switching input language.

1) 2-set Korean.
2) No, Safri works as expected.
3) If I launch Chromium with Korean IME being set, it never works as expected.

- When I press shortcuts right after switching to Korean from English(type nothing), sometimes it works. In that case, IME suddenly switched to English while I press cmd key. After I release cmd key, it switched back to Korean and the feature gets broken again.

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

commit 30e11c9e9b9f5ab322a5c5fdb107e62b44d6215b
Author: erikchen <erikchen@chromium.org>
Date: Mon Oct 01 15:10:48 2018

macOS: Process uppercase keyEquivalents for non-ascii characters.

The logic in NSMenuItem(ChromeAdditions) attempts to mimic Cocoa's logic for
determining whether a NSMenuItem will fire for a given NSEvent.

In keyboard layouts that produce non-ascii characters, Cocoa uses the event's
"characters" property to process keyEquivalents, and will manually apply the
shift modifier if necessary. Our logic was failing to do so. This meant that key
combinations such as [cmd + shift + t] on 2-Set Korean would attempt to match a
NSMenuItem with keyEquivalent "t" rather than a NSMenuItem with keyEquivalent
"T".

Bug:  889970 
Change-Id: I81fdf11c4ffa6322d78e981cdbff6956cd8f4b79
Reviewed-on: https://chromium-review.googlesource.com/1254462
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#595453}
[modify] https://crrev.com/30e11c9e9b9f5ab322a5c5fdb107e62b44d6215b/chrome/browser/ui/cocoa/nsmenuitem_additions.mm
[modify] https://crrev.com/30e11c9e9b9f5ab322a5c5fdb107e62b44d6215b/chrome/browser/ui/cocoa/nsmenuitem_additions_unittest.mm

This bug requires manual review: We are only 13 days from stable.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

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

Let's verify this in Canary tomorrow. 

Erik - how does this change look in canary today?

Looks good to me.

branch:3538

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

commit a03bbb2911c101f82ea2b726e8fe7ffda632c5d2
Author: erikchen <erikchen@chromium.org>
Date: Wed Oct 03 15:31:08 2018

[Merge to 3538] macOS: Process uppercase keyEquivalents for non-ascii characters.

The logic in NSMenuItem(ChromeAdditions) attempts to mimic Cocoa's logic for
determining whether a NSMenuItem will fire for a given NSEvent.

In keyboard layouts that produce non-ascii characters, Cocoa uses the event's
"characters" property to process keyEquivalents, and will manually apply the
shift modifier if necessary. Our logic was failing to do so. This meant that key
combinations such as [cmd + shift + t] on 2-Set Korean would attempt to match a
NSMenuItem with keyEquivalent "t" rather than a NSMenuItem with keyEquivalent
"T".

Bug:  889970 
Change-Id: I81fdf11c4ffa6322d78e981cdbff6956cd8f4b79
Reviewed-on: https://chromium-review.googlesource.com/1254462
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#595453}(cherry picked from commit 30e11c9e9b9f5ab322a5c5fdb107e62b44d6215b)
Reviewed-on: https://chromium-review.googlesource.com/c/1258026
Reviewed-by: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#837}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/a03bbb2911c101f82ea2b726e8fe7ffda632c5d2/chrome/browser/ui/cocoa/nsmenuitem_additions.mm
[modify] https://crrev.com/a03bbb2911c101f82ea2b726e8fe7ffda632c5d2/chrome/browser/ui/cocoa/nsmenuitem_additions_unittest.mm

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

Commit: a03bbb2911c101f82ea2b726e8fe7ffda632c5d2
Author: erikchen@chromium.org
Commiter: erikchen@chromium.org
Date: 2018-10-03 15:31:08 +0000 UTC

[Merge to 3538] macOS: Process uppercase keyEquivalents for non-ascii characters.

The logic in NSMenuItem(ChromeAdditions) attempts to mimic Cocoa's logic for
determining whether a NSMenuItem will fire for a given NSEvent.

In keyboard layouts that produce non-ascii characters, Cocoa uses the event's
"characters" property to process keyEquivalents, and will manually apply the
shift modifier if necessary. Our logic was failing to do so. This meant that key
combinations such as [cmd + shift + t] on 2-Set Korean would attempt to match a
NSMenuItem with keyEquivalent "t" rather than a NSMenuItem with keyEquivalent
"T".

Bug:  889970 
Change-Id: I81fdf11c4ffa6322d78e981cdbff6956cd8f4b79
Reviewed-on: https://chromium-review.googlesource.com/1254462
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#595453}(cherry picked from commit 30e11c9e9b9f5ab322a5c5fdb107e62b44d6215b)
Reviewed-on: https://chromium-review.googlesource.com/c/1258026
Reviewed-by: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#837}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}

I also use 2-set Korean and still has the same issue. If it is fixed, can anyone tell me how to fix it?

Hello, ywjulie1013@!

I guess you're using chrome 69 version but it seems the fix wasn't landed to 69. As newer version will be released on 10/16(PT) - it might be 10/17 in Korea - you can wait for it. Or you can use dev channel or canary til then. Thanks :)