Closed Bug 562776 Opened 13 years ago Closed 13 years ago

Buttons in digest pane are using the same access key multiple times

Categories

(Toolkit :: Add-ons Manager, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.3a5
Tracking Status
blocking2.0 --- final+

People

(Reporter: whimboo, Assigned: mkohler)

References

Details

(Whiteboard: [rewrite])

Attachments

(2 files, 1 obsolete file)

Attached image screenshot
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100427 Minefield/3.7a5pre

When you have the digest pane open for any type of add-on open, the same access key is used for the Enable, Disable, Remove buttons. We have to avoid that. An access key should only be used once.
Sadly, the solution to that problem is to completely remove the access keys.
As long as we wanna show the buttons for all add-ons in that list even when the add-on isn't selected, it's true.
Keywords: uiwanted
Priority: -- → P2
I'm removing uiwanted - seems to be on dev side
Keywords: uiwanted
Jennifer, the reason why I have added the uiwanted keyword is, if we really wanna show up the buttons for all entries, even when they are not selected. In the old ui only the selected items shows buttons for enabling/disabling/removing an extension.
Keywords: uiwanted
Blocks: 563909
Bug 563912 is closely related to this one. Having to havigate using tab through all those buttons for all extensions makes the keyboard interaction model really cumbersome.
(In reply to comment #2)
> As long as we wanna show the buttons for all add-ons in that list even when the
> add-on isn't selected, it's true.

Agreed, we should remove the access keys.  For accessibility I'm guessing we'll need to implement a way to expand any add-on just using the keyboard, for instance by cycling focus and then having an access key just on one item.  For now let's just take out access keys.
Keywords: uiwanted
blocking2.0: --- → final+
Duplicate of this bug: 567658
Attached patch Patch (obsolete) — Splinter Review
AFAIC there are no other accesskeys to delete.
Assignee: nobody → michaelkohler
Status: NEW → ASSIGNED
Attachment #447022 - Flags: review?(dtownsend)
When we are going to remove the accesskeys we also have to update the dtd files, if the same access keys aren't used anywhere else.
Comment on attachment 447022 [details] [diff] [review]
Patch

Need to remove the relevant entities in extensions.dtd too.

Also, there's code in extensions.xml that handles the accesskey attributes for the "Show more" toggle button - that will need removed too (its in the toggleDetails method).
Attachment #447022 - Flags: review?(dtownsend) → review-
Attached patch Patch v2Splinter Review
Attachment #447022 - Attachment is obsolete: true
Attachment #447073 - Flags: review?
Attachment #447073 - Flags: review? → review?(bmcbride)
Michael, why doesn't the new patch contain the lines from patch 1? Was that by accident?
(In reply to comment #12)
> Michael, why doesn't the new patch contain the lines from patch 1? Was that by
> accident?

Huh? Looks like it does include those changes.
Attachment #447073 - Flags: review?(bmcbride) → review+
(In reply to comment #13)
> (In reply to comment #12)
> > Michael, why doesn't the new patch contain the lines from patch 1? Was that by
> > accident?
> 
> Huh? Looks like it does include those changes.

What about extensions.xul? Don't we have to remove the enable/disable/remove accesskeys there too, which would also require to remove those from the dtd file?
(In reply to comment #14)
> What about extensions.xul? Don't we have to remove the enable/disable/remove
> accesskeys there too, which would also require to remove those from the dtd
> file?

No, that's the detail view - we don't have this problem in the detail view.
Keywords: checkin-needed
Landed: http://hg.mozilla.org/mozilla-central/rev/03776449f410
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
Verified fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100530 Minefield/3.7a5pre (.NET CLR 3.5.30729) ID:20100530040319
Status: RESOLVED → VERIFIED
Flags: in-testsuite-
Flags: in-litmus-
You need to log in before you can comment on or make changes to this bug.