This is a regression from bug 380637. The doorhanger accesskeys for some letters close the doorhanger, but don't trigger intended action. Steps to reproduce (Windows 8.1, all builds after bug 380638 landed): 1. Open https://permission.site/ 2. Click on "Notifications". 3. Press Alt + N for "Not Now". Actual result: Doorhanger closes, and gets immediately opened again. Expected result: Doorhanger closed, "Notification" button gets red background. This also can fail silently. E.g. the prompt to update address or credit card data or save it as new data fails silently. Further observations show that e.g. "h" works as accesskey but "n" doesn't. [Tracking Requested - why for this release]: Regression, breaks accessibility and actions can fail silently.

Track 58+ as regression.

Pushed by neil@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/76990027c9f8 don't close the menu in nsMenuBarFrame::FindMenuWithShortcut when just checking if such a menu shortcut key exists from the keydown event handler, also for extra safety this should only happen for menus not panels, r=felipe

This doesn't seem like the kind of patch we'd want to risk taking in a dot release, so calling this wontfix for 58. Feel free to set it back to affected and nominate for mozilla-release approval if you feel strongly otherwise, however.

I have managed to reproduce the issue mentioned in comment 0 using Firefox 59.0a1 (BuildId:20171230220352). This issue is verified fixed on Firefox 60.0a1 (BuildId:20180206220102) and 59.0b7 (BuildID:20180205211730) using Windows 10 64bit.