Closed Bug 946395 Opened 6 years ago Closed 6 years ago

Back out bug 881937 which made the panel menu keyboard accessible

Categories

(Firefox :: Toolbars and Customization, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 29

People

(Reporter: dao, Assigned: dao)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P4])

Attachments

(1 file)

I've filed a (not necessarily comprehensive) list of bugs documenting where keyboard focus in the panel menu is incomplete or broken; see bug 881937's dependency list. I don't really think we should work on these bugs, but rather back out bug 881937 and focus on other Australis stuff. As I understand it, bug 881937 has always been a nice-to-have. That is, not having it is not a loss compared to pre-Australis.
Marking as P4 as I don't think the average user will run into this. I agree that we should do this though given the time bounds we have for Australis.
Summary: Back out bug 881937 → Back out bug 881937 which made the panel menu keyboard accessible
Whiteboard: [Australis:P4]
(In reply to Matthew N. [:MattN] from comment #1)
> Marking as P4 as I don't think the average user will run into this.

There's some aesthetic fallout (bug 946287) and bad impact on widgets that deal with focused content (bug 946297) affecting add-ons (since we've already worked around it for our edit controls).
Attached patch patchSplinter Review
https://tbpl.mozilla.org/?tree=Try&rev=32536cd6bb3c
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #8364432 - Flags: review?(gijskruitbosch+bugs)
Comment on attachment 8364432 [details] [diff] [review]
patch

Review of attachment 8364432 [details] [diff] [review]:
-----------------------------------------------------------------

r=me assuming you get an OK from phlsa. From what I understand UX is still thinking this through.

::: browser/components/customizableui/content/panelUI.js
@@ -143,5 @@
>                                                  "toolbarbutton-icon");
> -
> -      // Only focus the panel if it's opened using the keyboard, so that
> -      // cut/copy/paste buttons will work for mouse users.
> -      let keyboardOpened = aEvent && aEvent.sourceEvent &&

If we're no longer doing this we should stop passing this event (or ugly mocks of it in the tests) around. That should probably be a separate patch to keep things neat, but I'd like it to be done sooner rather than later.
Attachment #8364432 - Flags: ui-review?(philipp)
Attachment #8364432 - Flags: review?(gijskruitbosch+bugs)
Attachment #8364432 - Flags: review+
(In reply to :Gijs Kruitbosch from comment #4)
> Comment on attachment 8364432 [details] [diff] [review]
> patch
> 
> Review of attachment 8364432 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r=me assuming you get an OK from phlsa. From what I understand UX is still
> thinking this through.

My take-away from the work week is that we don't have the resources to properly finish keyboard access support (or that it's not enough of a priority to spend the required resources on it) and I'd be surprised if UX people found the current state satisfying, but okay, I'll wait and see.
https://hg.mozilla.org/mozilla-central/rev/801cab0388a2
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
No longer blocks: 962730
You need to log in before you can comment on or make changes to this bug.