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

VERIFIED FIXED in mozilla1.9.3a5

Status

()

defect
P2
normal
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: whimboo, Assigned: mkohler)

Tracking

Trunk
mozilla1.9.3a5
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -
in-litmus -

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [rewrite])

Attachments

(2 attachments, 1 obsolete attachment)

Posted 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
Assignee

Comment 8

9 years ago
Posted 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-
Assignee

Comment 11

9 years ago
Posted patch Patch v2Splinter Review
Attachment #447022 - Attachment is obsolete: true
Attachment #447073 - Flags: review?
Assignee

Updated

9 years ago
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.
Assignee

Updated

9 years ago
Keywords: checkin-needed
Landed: http://hg.mozilla.org/mozilla-central/rev/03776449f410
Status: ASSIGNED → RESOLVED
Last Resolved: 9 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.