Best alternative I can think about would be to ask user first time when ⌘Q is pressed what is preferred behaviour.
But enabling "Hold ⌘Q to Quit" is big and unnecessary violation of macOS user experience.

shchvova@ Thanks for the issue.

CC'ing thomasanderson@ from  issue 869185  to check and update on this further.

Thanks..

Thanks for your feedback. I am the Mac Chrome tech lead and this was my decision.

I understand that cmd-q not instantly quitting Chrome is different behavior from other macOS apps, but this was a conscious decision on our part: cmd-q is adjacent to cmd-w, which is one of the most commonly used Chrome keyboard shortcuts. The macOS HIG for keyboard interaction (<https://developer.apple.com/design/human-interface-guidelines/macos/user-interaction/keyboard/>) states:

"""
*In general, don’t override standard keyboard shortcuts.* Users may become confused if the shortcuts they know work differently in your app. Only in very rare cases does it make sense to redefine a common shortcut. For example, if people spend a significant amount of time in your app, it might make sense to redefine a standard shortcut that isn’t applicable to your app. Another option might be to let the user choose their own keyboard shortcuts.
"""

Emphasis Apple's. We considered this passage from the HIG while making this decision. In our view, the potential downside of having cmd-q behave this way by default (i.e., user has to hit cmd-q again, or disable the option) was far smaller than the potential downside of leaving the old cmd-q behavior (i.e., users accidentally destroying their entire browser session, especially in situations without session restore). As such we decided that this is one of the "very rare cases" in mention. So far, user feedback has justified this decision: the rate of user reports that they accidentally hit cmd-q while attempting to use cmd-w and lost work/state/etc has dropped to nearly nil.

I am prepared to entertain an argument that the default should be for cmd-q to immediately quit, but in the absence of unambiguous language from the HIG requiring it, the fact that other Mac apps quit right away on cmd-q is not compelling enough - i.e., I don't think we should sacrifice the very real user benefit of avoiding accidental quits in exchange for consistency with other Mac apps here.

As such, I'm marking this bug WontFix for now.

Thank you for extended reply. It is your decision, and reasoning is justified. There's ⌘⇧T shortcut which will restore session if you accidentally quit the app. It is not a fair metric to compare reduction of reports (which you can measure) to increase of annoyance of everyone who doesn't like default OS behaviour broken (which you can't).

I think there is much better way to introduce such breaking change.
- Ask user first time ⌘Q is pressed what desired behaviour is
- Let user know about existence of the option to enable/disable this behaviour.
- Mirror "Warn before Quitting" in "Settings". I couldn't find option in settings, and it's only setting in app menu

If 2 out of 3 of this would be implemented, I believe it would be great feature without downsides I described in the ticket.

This change drove a 50% increase in the number of reports about keyboard shortcuts not working. See: http://shortn/_mQnSKA9c1E for some of the reports.

There's a setting you can toggle to make ⌘Q quit instantly.  In the top menu bar: Chrome > Warn before quitting (⌘Q)

#6: That's good to know, thanks. We may revisit this in future if those reports don't level off.

 Issue 900144  has been merged into this issue.

Its kinda annoying to have to find the fix for an platform-alient behaviour on the ticketing tool. It would be nice to- if not revert the behaviour- at least to prominently display the hint how to disable it?

We're tracking adding this to Settings (to make it easier to find) in  issue 900293 .

See also the 300 comments on  issue 147 .

The original feature was implemented in  issue 115709 .

 Issue 243164  has another ~140 comments.