465090 - Add keyboard shortcut to open Addons Manager

Status: VERIFIED FIXED

(Firefox :: Keyboard Navigation, defect)

Description

[Tony Chung [:tchung]]

Can we get a keyboard shortcut to pull up the addons manager?  Makes sense, since we have one for practically every other popup dialog from the context menu.

Comment 1

[Robert Strong (they/them - no direct email)]

Any app can choose to do this and this would actually need to be done in the Firefox code so moving to a more appropriate component.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Talked to Jennifer about that on IRC and she will look into this. Would be nice to have it for the new addons manager.

Given the test pilot study this entry is one of the most used entries in the tools menu: http://people.mozilla.com/~faaborg/files/20100322-menuBarHeatMap/menuBarHeatMap-i1.png_large.png

I'll add the dependency to bug 550048 so we have it on our tracking list.

Comment 3

[Jennifer Morrow [:Boriss] (UX)]

This is definitely a missing piece.  For consistency, a similar command to Organizing Bookmarks (Ctrl-Shift-B) should be used.

As Henrik and Fligtar pointed out, Ctrl-Shift-A is taken.  Ctrl-Shift-M seems to be available

Does anyone know if Ctrl-Shift-M is taken on any OS?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Not that I'm aware of, but chances are high to break an extension. But we are early in the cycle, so it shouldn't be a problem.

Comment 5

[Paul [pwd]]

Why M? It seems as silly as Alt+S for History or Ctrl+J for downloads. A = Add-On's is fine, E = Extensions is fine. Anything outside of that isn't very intuitive.

Comment 6

[Jennifer Morrow [:Boriss] (UX)]

(In reply to comment #5)
> Why M? It seems as silly as Alt+S for History or Ctrl+J for downloads. A =
> Add-On's is fine, E = Extensions is fine. Anything outside of that isn't very
> intuitive.

A isn't available, unfortunately.  E is available, but "extension" is not a word that's being used in the title of the manager (only a section within it).  So, it would be the same hierarchy-wise as choosing "P" for plug-ins or "L" for language packs.  I'm going to recommend M because it's at least the starting word of Manager, which is in the add-on manager's title.

Comment 7

[Paul [pwd]]

(In reply to comment #6)
> (In reply to comment #5)
> > Why M? It seems as silly as Alt+S for History or Ctrl+J for downloads. A =
> > Add-On's is fine, E = Extensions is fine. Anything outside of that isn't very
> > intuitive.
> 
> A isn't available, unfortunately.  E is available, but "extension" is not a
> word that's being used in the title of the manager (only a section within it). 
> So, it would be the same hierarchy-wise as choosing "P" for plug-ins or "L" for
> language packs.  I'm going to recommend M because it's at least the starting
> word of Manager, which is in the add-on manager's title.

I believe that the current system and shortcuts need reviewing them. Clearly the program has outgrown the legacy keyboard shortcuts from an internet of yesteryear where there was a lot less to go round. I believe the UX team should be championing this change. No matter how you look at is, things like alt+S and this proposed alt+M aren't intuitive and in fact hinder usage rather than expedite it.

Comment 8

[Robert Strong (they/them - no direct email)]

When reasonable I agree with comment #7 but ctrl+a (at least on Windows) is select all which is the standard for select all and is for all practical purposes the same on all applications that support select all (once again, at least on Windows). Making users have to remember to use a different key combination for a standard action (e.g. copy, cut, paste, select all, etc.) for Firefox while all other apps (once again, at least on Windows) use the standard key combination is not going to happen.

Personally, I think ctrl+m is the next best choice.

Comment 9

[Paul [pwd]]

(In reply to comment #8)

You're right, Ctrl+A, V, C, P, N, L, T, W aren't feasible. But that's not to say that by default, the next best thing is correct. 

Alt+[letter] is supposed to be top level. C+[letter] is supposed to be global, surely if you're extending beyond that, then for usability, have what you want at a third level Ctrl+Shift+[letter]/Alt+Shift+[letter]/Alt+Ctrl+[letter], etc. As I said, it needs to be intuitive.

A review of the system at this point would be idealistic, as we're going into Firefox 4. It's better to break the system completely and create room for exponential growth than continue to try and leverage cramped space. At least with a drastic change that is intuitive it allows the natural growth of Firefox within a working system you deal with these issues now, before you're left with no choice. And if you do it now, you can always provide an extension to assign old keyboard shortcuts which should alleviate any backlash from the community and allow people to convert at their own pace. It'd also put Firefox in a good position for this world of web apps where browser use is going to be greatly increased.

With the third level, you also create room for extensions to grow on that platform. The idea in my opinion, is at least worth discussing. As the current system is broken and with the Firefox button coming, there's no better time to implement such major changes.

Comment 10

[Robert Strong (they/them - no direct email)]

I believe the next best after ctrl+a is ctrl+m and that it is the correct choice in this instance. IMO the next best choice would be ctrl+shift+a especially since that is used for several other keyboard shortcuts under Tools. I also believe that ctrl+m is more intuitive than any of the three key shortcuts though keyboard shortcuts are seldom intuitive beyond the standard shortcuts for the average user including those that use keyboard shortcuts often. Also, making keyboard shortcuts intuitive is well outside of the scope of this bug... I know there have been discussions in the UX team of making keyboard shortcuts much more easily discoverable. Extending available shortcuts is also well outside the scope of this bug.

Comment 11

[Paul [pwd]]

But when you talk about adding a keyboard shortcut, surely that discussion becomes relevant. We have the main application specific shortcuts like Alt+B which we know will bring up a menu. And then you create Ctrl+Shift+[letter] for all specific actions like displaying the AOM or DM manager. If you create that prescedent/standard at this point, and break legacy behaviour now. The idea is to implement the new AOM as a tab and Firefox button at the same time. Granted it's outside the scope of this bug, but this bug should be blocked until a decision on keyboard shortcuts has been had and a resolution come to.

BTW, CTRL+Shift+A does nothing on my installation, though IMO, even if it did, now is the time to break it in order to facilitate this bug and the progression of the platform as a whole.

Comment 12

[Robert Strong (they/them - no direct email)]

Going with ctrl+shift+a is not more intuitive as I see it. Making keyboard shortcuts always use the first letter of the text will likely not always be feasible in en-US much less in all locales and it won't make the shortcut intuitive IMO. Making keyboard shortcuts easier to discover is IMO much more important. If it were decided to change keyboard shortcuts so they followed what you are advocating the only reason this bug would be blocked would be because someone was an advocate for this change since it is trivial to change the keyboard shortcut later.

If you believe all keyboard shortcuts should be reviewed / changed to follow what you are advocating please file a bug in Firefox -> Keyboard Navigation with the details.

Comment 13

[Dave Townsend [:mossop]]

We can either block this bug on a review of all keyboard shortcuts (which I haven't heard is a priority for UX right now), or we can implement this bug with the available shortcut that seems most sensible right now and if UX do a shortcut review then it will be included and updated at that point. The only reason not to do the latter would be that it might mean the initial shortcut we introduce is shortlived, but since any shortcut review will likely break even longer lived shortcuts I don't think that is an issue worth talking about. On the plus side if the review never happens at least we'll get our shortcut.

As for what to use, Ctrl-M may work on windows and linux but on OSX Cmd-M means minimize. For consistency it may be better to just go for Ctrl(/Cmd)-Shift-A on all platforms which at first glance appears to be available.

Comment 14

[Paul [pwd]]

OK, so Ctrl/Cmd+Shift+A(dd-ons) is supported for the bonus of cross-platform consistency. And then when the new Download Manager lands, I'll file a bug to move that to Ctrl/Cmd+Shift+D and hopefully that'll kick off the shortcut review and we can move all actions to Ctrl/Cmd+Shift+[letter].

Comment 15

[Dave Townsend [:mossop]]

(In reply to comment #14)
> OK, so Ctrl/Cmd+Shift+A(dd-ons) is supported for the bonus of cross-platform
> consistency. And then when the new Download Manager lands, I'll file a bug to
> move that to Ctrl/Cmd+Shift+D and hopefully that'll kick off the shortcut
> review and we can move all actions to Ctrl/Cmd+Shift+[letter].

Or better, just file a bug (if there isn't already one) to request a shortcut review and post about it in the newsgroups.

Comment 16

[Paul [pwd]]

(In reply to comment #15)
> (In reply to comment #14)
> > OK, so Ctrl/Cmd+Shift+A(dd-ons) is supported for the bonus of cross-platform
> > consistency. And then when the new Download Manager lands, I'll file a bug to
> > move that to Ctrl/Cmd+Shift+D and hopefully that'll kick off the shortcut
> > review and we can move all actions to Ctrl/Cmd+Shift+[letter].
> 
> Or better, just file a bug (if there isn't already one) to request a shortcut
> review and post about it in the newsgroups.

Done: [[bugzilla:564798]]

Comment 17

[Paul [pwd]]

Sorry folks.

bug 564798

https://bugzilla.mozilla.org/show_bug.cgi?id=564798

Comment 18

[imradyurrad]

Just making sure nobody forgot about this =]

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I will give it a try. Dave would be great if you could give me some help for the browser chrome test if necessary.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Dave, would the following folder the right one for a browser-chrome test:
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/test/browser/

Also, are there any components I could re-use for the test, like a check if the tab is open or not.

Comment 21

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Yea, that'd be the right place for it. Don't think we have any function to check if its already open in a tab yet (see head.js in that directory). Would be a good idea to add a function to that file though.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Patch v1 (w/o test)

The string freeze for beta 5 is coming closer and I don't see a chance that I can add tests for the keyboard shortcut in the near future. This patch contains everything which is needed to have a working shortcut.

Dave, I can definitely try to get some tests written at a later point, and we will definitely have one with Mozmill, which is probably a better idea because the shortcut can even be tested in localized builds and not only for en-US.

Comment 23

[Dave Townsend [:mossop]]

Comment on attachment 469030 [details] [diff] [review]
Patch v1 (w/o test)

Sorry I can't actually review this, dolske maybe?

Comment 25

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

http://hg.mozilla.org/mozilla-central/rev/1f958cf3e8ec

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks for landing the patch Kyle! As soon as I have time I will check for the requested automated test. The manual and Mozmill one will probably be implemented earlier.

Comment 27

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed with builds on all platforms like Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Added to Litmus:
https://litmus.mozilla.org/show_test.cgi?id=10143

Comment 29

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Dave, I'm currently working on Mozmill tests and this could be one good candidate which we could test in even localized builds. Do you still want to have it as a browser chrome test or is a Mozmill test good for you?

Comment 30

[Dave Townsend [:mossop]]

(In reply to comment #29)
> Dave, I'm currently working on Mozmill tests and this could be one good
> candidate which we could test in even localized builds. Do you still want to
> have it as a browser chrome test or is a Mozmill test good for you?

As long as the mozmill tests are getting run on a regular basis then I'm fine with covering it there

Comment 31

[Aaron Train [:aaronmt]]

Attachment: Mozmill Test - New AOM (v1) - (default)

Comment 32

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Comment on attachment 480257 [details] [diff] [review]
Mozmill Test - New AOM (v1) - (default)

>+var testOpenAOMShortcut = function() {
>+  addonsManager.open({type: "shortcut"});
>+  controller.assert(function() {
>+    return addonsManager.isOpen == true;
>+  }, "Add-ons manager should open");

This covers only one single step in the Litmus test. There is a lot more we should do here. Was it open before? Do we focus the correct tab? What about multiple windows? And when users have opened the manager manually in a tab beside the other open add-ons manager tab?

Lets have a much deeper testing with this Mozmill test. Given that please rename the test to testOpenClose.js because you also will have to test for closing. 

>+/**
>+ * Map test functions to litmus tests
>+ */
>+// testOpenAOMShortcut.meta = {litmusids : [10143]};

Please don't add this mapping.

Comment 33

[Maniac Vlad Florin (:vladmaniac)]

Attachment: patchv1.0 all branches

Asking for feedback for this patch from Henrik

Tested with all branches 

Litmus test: https://litmus.mozilla.org/show_test.cgi?id=10143

Comment 34

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Vlad, anything Mozmill related please as a new bug in our own component. Thanks.

Comment 35

[Maniac Vlad Florin (:vladmaniac)]

Filed bug 669600. Thanks