This is almost certainly because of your remapping.

https://chromium.googlesource.com/chromium/src/+/51deeb7261c8b729e179362df5698ce11558c6bd/content/browser/renderer_host/render_widget_host_view_mac.mm#2030

It looks like I wrote this DCHECK 7½ years ago (https://chromium.googlesource.com/chromium/src/+/5a9e2bfd0241f824cda5ec92054d857d0dfb7599), but really, I was just removing Nico’s tabs (https://chromium.googlesource.com/chromium/src/+/5c87690ac9aed7e975132b301aed90abbe4e0550).

The DCHECK isn’t unreasonable, we don’t want shortcuts that don’t use Command but use some other modifier in our default set of shortcuts. But the concern then was probably more that someone would borrow a Windows shortcut that used Control without coming up with a proper one for Mac.

If this is interfering with remapped keys, we should probably just get rid of the DCHECK.

I think the DCHECK is there because things depend on it here: https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_mac.mm?type=cs&q=%22Make+sure+the+menu+does+%22+package:%5Echromium$&l=2037 I don't remember details but I think it was kind of important somehow. Should've wrote a comment.

I apologize for adding tabs :-(

I tried and confirm that this goes away if I don't remap Meta-T to Ctrl-T.
FWIW on official builds, where we don't hit this because is a DCHECK, remapped keys seem to work fine as I've been using that on my corp and personal laptop for 3+ years.
(I know, I am a bad person, I remap hotkeys to match Linux/Windows and I keep saying "symbolization" instead of "symbolication")

On one side it feels to me that a user action (remapping keys) can cause a DCHECK to be hit, which suggests that either the DCHECK is wrong or too broad.
On the more concrete side the impact of this bug seems to be restricted to people who run chrome with dcheck_always_enabled on a mac with remapped keys. Which is perhaps just a very long periphrasis to say strcmp("primiano", getenv("USER")).
Given the not-so-wide userbase, I guess figuring the details of this is not really worth anybody's time, as we all have more important battles to fight.

[mac triage]

Our story for supporting users remapping things via Prefs -> App Shortcuts is probably incomplete..

For example "Cmd+t" is not sent to a webcontents on Mac, because
 - websites can not preventDefault on it to prevent you making new tabs
 - commands are less responsive when giving webcontents' javascript an opportunity to see the event first

That `return NO` after the DCHECK makes this still work the same (somewhat coincidentally) for Cmd+t, since it is reserved.

But it will do strange things for non-reserved things like Cmd+f.

E.g. google docs wants to intercept Cmd+f on Mac to show its own find bar. By remapping it to Ctrl+f, and hitting that early exit after the DCHECK, Chrome is bypassing the logic that would have let google docs peek at it and prevent chrome showing the default find bar.

(E.g., I think for you with Find... mapped to Ctrl+f, Cmd+f and Ctrl+f in google docs will show different find bars).



(Also Ctrl+t is an editing command on Mac to transpose characters either side of the cursor. returning NO from performKeyEquivalent could theoretically end up in the -transpose: method that's added at runtime to RenderWidgetHostViewCocoa by RenderWidgetHostViewMacEditCommandHelper --  https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_mac.mm?q=AddEditingSelectorsToClass+package:%5Echromium$&l=1766 but that doesn't seem to happen when a menu item is triggered.



We probably do want an "intentional" fix here, but I don't know what it is.. (and it will be super complicated because command-key processing on Mac is super complicated to begin with, even for a single process app). Anyway, this particular DCHECK failure probably isn't high priority, but I'll probably need to put some more thought into this when we start using views::WebView on mac, and/or start supporting plugin-IME on Mac.

> (E.g., I think for you with Find... mapped to Ctrl+f, Cmd+f and Ctrl+f in google docs will show different find bars).

Yup your comment is spot on. That's my experience, although it never bothered me too much, because I don't know what is the expectation of the hotkeys of an app (docs) that doesn't allow me to customize them.

"this particular DCHECK failure probably isn't high priority"

All DCHECKs should be treated with the same priority as a crash or removed. DCHECK should be used to document invariants that never occur. If we know something occurs and can live with it, we should remove the DCHECK.

I don't think we should remove the check. This issue is identifying a niche OS feature that Chrome doesn't have full support for (and implementing full support for it is not high priority). Its use here was successful in identifying the use case leading up to the gap in Chrome's support and allowed a developer to report it without unnecessarily impacting users. If a future Chrome developer writes a test or feature that hits this, they deserve to know that the current behaviour is unintentional.

For example, the DCHECK here will correctly crash if a developer modifies Chrome's default shortcuts to include Control but not Command on Mac - that's an invariant that should never occur, and we don't want to live with it in Chrome's default configuration, nor on any trybots.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

Triage: Assigning to erikchen@ who's looking into hotkeys again for the MacViews integration.

*** UI Mass Triage ***