Good work and good progress on the recent implementation [1] of the contextMenus on the browser_action and page_action contexts. Much appreciated!
However, I have some feedback about the UX.
I find it very cluttered to force all the other menu items there (which are not of interest when clicking an browser_action context), and to have my add-on menu items thrown in with no icon for differentiation, merely on top with a small separator line. Also the 6-item limit is very restrictive, and compounded by the superfluous other menu items which just waste screen space.
Additionally, this static calculation of 6 items, and all our other items which you don’t need right now and probably never use anyways, is ridiculous. I understand that some limit may be advisable for very small screens, and low resolution devices (such as mobile phones). But seriously, on a desktop computer (for which I am primarily developing), with about 16" from top to bottom of screen, these restrictions create an arbitrary limitation of menu size, which result in a tiny menu barely 4" high, leaving 75% of vertical space wasted.
Granted, I don’t necessarily want to use all that space, but my point is that rather than calculate a static limit for the lowest common denominator, I think a dynamic calculation would be better, or a limit based on platform and/or screen size, or a scrolling menu, or the freedom to remove ALL unused and undesirable menu items, or forcing those menu items only when it makes sense.
The menu items in question:
- Move to Menu (puts into Hamburger menu, which is cluttered and full of other unused things, and hidden from view, which can be - and almost always is - done through the Customize feature)
- Remove from Toolbar (which puts it into the pool of Customize icons)
- Menu Bar (which allows you to toggle the menu bar, default off, best kept on, usually can click anywhere in the empty tab bar area, but this can be very tricky if tab bar is full, but oh, it is always available on the hamburger icon which is always available in the same spot)
- Bookmarks Toolbar (exactly the same toggle locations as Menu Bar)
- Customize (which is functionally equivalent to clicking the Hamburger icon, which is always there)
In short, these 5 additional menu items are all redundant. They are infrequently used, of little value, and already available in a consistent location.
The use-case of these browser_action enabled add-ons is that they go into “The Add-on Bar” (or Classic Theme Restorer), and sit along the bottom of the browser, not cluttering up the address bar. All the add-ons that I most commonly use (many are still XUL or SDK based) have their own “clean” context menus. To force the addition of 5 menu items of little or no value, on each and every single browser_action, is ludicrous.
I understand that some uniformity of menus is desirable, as is some parity with Google Chrome, as is the ability to ensure some of these menu items are always available if someone might want them. But there is a point when parity and uniformity for the sake of themselves, are detrimental to user experience, especially in the case of spammy menu items.
Might this be a candidate for a UX bug or feature request?
- Remove 5 redundant context menu items from browser_action context
- Dynamically set a menu item limit, based on platform, screen size, or allow for scrolling, or some other as yet undetermined algorithm. Push the code upstream into Google if parity is of that much importance. But don’t settle for an overly-simplified and inferior UX design simply because we’re followers, not leaders anymore.