"Close this message" button of Notification bar is missing an accesskey.

RESOLVED INVALID

Status

()

Toolkit
Notifications and Alerts
--
trivial
RESOLVED INVALID
10 years ago
4 years ago

People

(Reporter: MarcoZ, Assigned: MarcoZ)

Tracking

({access})

Trunk
access
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

10 years ago
STR:
1. Perform any action that prompts a notification bar to appear. For example, log into an account where Firefox asks to save the password.

Notice: While the "Save password", "Don't save" etc. buttons all have an accesskey, the "Close this message" button does not.
(Assignee)

Comment 1

10 years ago
Created attachment 328252 [details] [diff] [review]
Patch
Attachment #328252 - Flags: review?
(Assignee)

Updated

10 years ago
Attachment #328252 - Flags: review? → review?(gavin.sharp)
I think we omitted this accesskey intentionally because that button is in the tab order, and it could potentially conflict with passed-in button accesskeys (part of the notificationbar API). I'm not really sure which problem is worse...
Component: Widget → XUL Widgets
Product: Core → Toolkit
QA Contact: general → xul.widgets
(Assignee)

Comment 3

10 years ago
(In reply to comment #2)
> I think we omitted this accesskey intentionally because that button is in the
> tab order, and it could potentially conflict with passed-in button accesskeys
> (part of the notificationbar API). I'm not really sure which problem is
> worse...

This bug directly resulted from user feedback: I got several people mentioning to me that they find it inconsistent to hear accesskey announcements for the other buttons, but none for the "Close thie message" button. Also, this is a notification bar people expect to interact with differently than with a dialog.
As for the button being in the tab order: Other buttons that are added sensitive to the notification are also in the tab order, yet they do have access keys as well.

And for conflicts with other accesskeys: If we document that in English, C is taken for the "Close this message" button, which is always there, people are alerted and can choose a different one.
(Assignee)

Comment 4

10 years ago
Any more thoughts on this one?
Do you know what happens if this accesskey conflicts with one passed in by a user of this API?
(Assignee)

Comment 6

10 years ago
In "normal" Windows dialogs, every control with the same access key is focused in turn.
(Assignee)

Comment 7

9 years ago
Jamie this morning also expressed an interest in having an access key on the "Close this message" button.
Comment on attachment 328252 [details] [diff] [review]
Patch

Let's just do this. Sorry for the huge delay in response.
Attachment #328252 - Flags: review?(gavin.sharp) → review+

Comment 9

8 years ago
Ping? There seems to be a patch with r+ here, but no further action. Is this stale?
Bulk move to Toolkit::Notifications and Alerts

Filter on notifications-and-alerts-component.
Component: XUL Widgets → Notifications and Alerts

Comment 11

4 years ago
(In reply to James Teh [:Jamie] from comment #9)
> Ping? There seems to be a patch with r+ here, but no further action. Is this
> stale?
Yes this patch has bitrotted. However I don't think this bug is valid. The close button doesn't have a text label, a accesskey in this context doesn't make sense.
Whiteboard: [CLOSEME? INVALID/WONTFIX]

Comment 12

4 years ago
Resolved per whiteboard
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
Whiteboard: [CLOSEME? INVALID/WONTFIX]
You need to log in before you can comment on or make changes to this bug.