Closed Bug 1427449 Opened 2 years ago Closed 2 years ago

doorhanger accesskeys for some letters (Alt + ...) close doorhanger, but don't trigger intended action

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P2, major)

defect

Tracking

()

VERIFIED FIXED
mozilla59
Tracking Status
firefox-esr52 --- unaffected
firefox57 --- unaffected
firefox58 + wontfix
firefox59 --- verified
firefox60 --- verified

People

(Reporter: aryx, Assigned: enndeakin)

References

Details

(Keywords: regression)

Attachments

(1 file)

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.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Flags: needinfo?(enndeakin)
Priority: -- → P2
Attachment #8941153 - Flags: review?(felipc) → review+
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
https://hg.mozilla.org/mozilla-central/rev/76990027c9f8
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
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.
Flags: qe-verify+
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.