Thanks for reporting the issue.

@johnbillion-- Could you please provide us the sample test url or test application to reproduce the issue and also please help us with the screencast of expected result/Actual issue.

Thanks!

[mac bug triage] Repro steps:

1. Go to https://itunes.apple.com/us/app/fetch/id407963172?mt=12
2. Click View in Mac App Store button

I marked this as a regression but I don't know for certain that it worked originally. Marking it RBS for now (depends on how hairy it is to fix).

dominickn@ - I believe you are the correct assignee?

This is impossible to fix without a bunch of work - namely replacing the entire dialog.

I discovered that NSAlert (which the dialog uses) will wire up Esc to respond to "Cancel" if and only if the string for the button is "Cancel". I imagine there's some similar behaviour for the primary button. (https://bugs.chromium.org/p/chromium/issues/detail?id=671658#c46)

Removing RBS and lowering priority for now.

Oops, submitted too early. To finish the thought, I did some exploration and couldn't find a way to wire up buttons to Esc/Enter in NSAlert aside from the default magic routing.

The "Don't open" button is changing back to Cancel in an upcoming release so "Esc" will work again to cancel the dialog. But getting Enter to work for the primary button will require replacing the dialog wholesale.

Setting keyEquivalents to \e or \r (or constants from key_equivalent_constsnts.h) should work . E.g. https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/javascript_app_modal_dialog_cocoa.mm?q=keyequivalent+javascript&sq=package:chromium&l=306

(we generally can't rely on the NSAlert magicness for the string "Cancel" since I doubt it is robust to translations).

Given that this should just be a matter of setting the key equivalent strings, and that the current dialog is really broken, bumping back to Pri-1 RBS.

tapted, shrike: thanks for the advice on this. I'm currently out of office so I can't address this until next week at the earliest.

Coincidentally, ben just fixed this in r499865.

Before that, this dialog had

  [allowButton setKeyEquivalent:@""];  // disallow as default

since r28145 (8 years ago). Dom's change for  Issue 601725  didn't change that.

Ben's change makes the string "Cancel" and makes allowButton default, so this bug is already fixed, at least for for US-English and maybe others. --secondary-ui-md will make the Esc-mapping not depend on strings.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-62; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-62 label, otherwise remove Merge-TBD label. Thanks.