Open Bug 599788 Opened 14 years ago Updated 2 years ago

Add-ons addressing extension menus should work with both traditional and new-style menu

Categories

(Firefox :: Menus, defect)

Product:
Firefox
Component:
Menus
Platform:
All
Windows XP
Type:
defect

Tracking

()

Status:
REOPENED
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: faaborg, Unassigned)

References

Details

(Keywords: dev-doc-needed) 

We were supposed to set up the Firefox menu with the ids of the traditional menu, so that if an extension modified the traditional menu (but the developer wasn't aware of the Firefox menu, perhaps because they were developing on Linux or OS X), the extension's menu item would still appear in the area above "Web Developer" and below "Print."

I may have really dropped the ball on this, I don't know for sure if we made the change (although it was mentioned in all of the mockups), and I don't know if it was discussed during code review.

If we haven't frozen yet we might want to get this quickly landed, since a lot of extension developers will be frustrated as they start to work on their extensions after feature freeze.  Ideally they shouldn't have to worry about traditional menu versus Firefox menu, and they should have to check or extend them differently.
blocking2.0: --- → ?
Blocks: 599779
Version: unspecified → Trunk
Bug 599779 is suggesting that they should be added to a submenu called "Extensions" rather than adding it to the actual menu itself. Is this what is going to happen, Alex? Personally, I would prefer it if it worked like in the mockup, but I wouldn't mind them being in a submenu either.

Or maybe if more than *X* extensions are added, they are placed in a submenu.
We would like extensions placed directly in the menu, so that the user doesn't have to go to the effort to access a sub-menu in third level UI to get to them.
see the more tools menu add-on
https://addons.mozilla.org/firefox/addon/2413/

I think i could expect similar behavior over here, except the extension will be a lot more popular.

You should probably mark this as won't fix.
(In reply to comment #0)
> We were supposed to set up the Firefox menu with the ids of the traditional
> menu, so that if an extension modified the traditional menu (but the developer
> wasn't aware of the Firefox menu, perhaps because they were developing on Linux
> or OS X), the extension's menu item would still appear in the area above "Web
> Developer" and below "Print."

The menu bar and the button are in the same document, so they can't use the same ids without gross hacks. Even if the items used the same ids, extensions overlaying the menu bar would still fail to overlay the button menu, since they specify an insertion point including a parent node (e.g. the File or View menu) which wouldn't exist in the button menu.

Extensions need to target the new menu explicitly with a second overlay.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
I suspect that as with the Status Bar -> Add-Ons bar, this is going to be a one-time pain thing that people are going to have to get used to.

Is there a JetPack API that does a clever thing here and overlays both menus intelligently? If not, we need to file a follow-up blocker on there being one.
blocking2.0: ? → ---
No matter what the technical reasons are (we can't have a data structure in two locations in our code base that refer to the same menu? really?), this is an extremely important thing to fix.

Here are a couple of cases illustrating the problem with the current approach:

* Add-on developer using Mac creates an extension that adds an entry to the Tools menu
* Windows 7 user installs said extension, gets no menu item anywhere since he's using the Firefox menu

Note that we have the *exact* same problem with the toolbar bookmarks menu vs. the native bookmarks menu; any extension adding an entry to this menu should be in both menus. Add in the bookmarks submenu in the Firefox menu, and you have three menus (all identical!) that the extension author has to compensate for, this will quite predictably be forgotten all the time.

I think this should block final, and it's indeed unfortunate that we didn't catch this earlier (and I feel I should take some of the blame for that, this is in the cross between UX and actual development, but I should have predicted it) — but I think it's going to be quite detrimental and chaotic if it doesn't get handled properly before we release.
Status: RESOLVED → REOPENED
blocking2.0: --- → ?
Resolution: INVALID → ---
(In reply to comment #6)
> No matter what the technical reasons are (we can't have a data structure in two
> locations in our code base that refer to the same menu? really?)

The menus aren't the same, they're structured differently, in the UI as well as under the hood. So what you can't have, given the tools currently used by add-ons, is a data structure targeting one specific menu but magically referring to two.

In addition to paving the jetpack path, we can document the app button menu structure on MDC for developers to refer to it without inspecting it live.
There is only one way to do this, and that's to make it so that the Firefox Button *replaces* the existing menuBar. This is why I was (repeatedly) pressing for the UX team to deliver a plan for how to harmonize the two sets of menus. If the Firefox Button were simply a different display of the same information, you'd get your magic. As long as they are two different things: no magic for you!

The JetPack API I whistfully referred to could make it easier for Add-On authors to overlay a menu and have it appear in both places. I think that should be our approach at this stage.
blocking2.0: ? → -
Summary: Extensions modifying the traditional menu should appear in the Firefox menu → Firefox Button and Firefox Menu should be the same thing (different renderings of same structure)
>Extensions need to target the new menu explicitly with a second overlay.

This really isn't ideal, but it sounds like we really don't have any other options.

Is there an existing insertion point in the Firefox menu, something obvious for them to use?  If we encourage extensions to place themselves anywhere (not that they can't do that anyway), we lose the benefits for users of having all of the extension commands placed in a single location in the menu.
>There is only one way to do this, and that's to make it so that the Firefox
>Button *replaces* the existing menuBar.

That breaks the muscle and human memory for users with a screen reader or who rely on keyboard access, and also doesn't help us with the objective of remaining consistent and familiar on XP.

I understand that having two parts of our interface reference the same ids is currently impossible, but that's an implementation detail that shouldn't change our overall strategy of external consistency with the platform.
(In reply to comment #9)
> Is there an existing insertion point in the Firefox menu, something obvious for
> them to use?  If we encourage extensions to place themselves anywhere (not that
> they can't do that anyway), we lose the benefits for users of having all of the
> extension commands placed in a single location in the menu.

There's no such preferred insertion point, no. Which benefits do you have in mind?
>There's no such preferred insertion point, no. Which benefits do you have in
>mind?

We would like all extensions to appear in the same area of the Firefox menu, so that when users add an extension they have a general idea of where the menu command is likely going to be.  This has been in all of the mockups to date, and also debated in dev.planning.  Obviously we can't force extensions to use this particular insertion point, but I would like us to document it as a best practice.
OS: Windows 7 → Windows XP
Summary: Firefox Button and Firefox Menu should be the same thing (different renderings of same structure) → Provide a preferred extension point in the Firefox menu
There is another possibility,I suppose, which would be to maintain the existing IDs and then create a mapping that slots them into the appropriate DOM structures (giving them new ID names as that's done, to avoid confusion). Basically insert a structure that does the translation.

I've no idea of the scope of that work, or the performance impact.
Isn't this a rather high priority bug? It should at least be blocking final.
(In reply to comment #14)
> Isn't this a rather high priority bug? It should at least be blocking final.

Agree completely.
Renominating again, I don't think we can expect extension developers to be aware of the UI differences on Windows 7.  If we aren't able to address this bug a lot of Windows users are going to have to start falling back to using the traditional menu bar if that is the only place they have access to their extensions.
blocking2.0: - → ?
I don't think there is any reasonable way to "address this bug" without some ugly hacks, and I think the costs of those hacks (developer confusion/unreliability/maintainability of code) outweigh the costs of not addressing this bug (some addons might forget about the Firefox menu).
Trying to improve the title, since this bug has morphed quite a bit. 

The important part is to provide a best-practice API call for this, so we can at least tell developers "this is how you make it show up for all platforms". If they continue to manually insert nodes into the DOM, that's unfortunate, but at least they need the ability to do the right thing. Whether that's something that is in Jetpack or elsewhere, I have no opinion on, but I do think solving this in *some* fashion is very important.
Summary: Provide a preferred extension point in the Firefox menu → Add-ons addressing extension menus should work with both traditional and new-style menu
We're not going to find a general solution that automatically forces the presence of extension-added menu items in both menus (there are too many ways to add menu items, so there's no reliable way to do that).

Finding a way to do it specifically for menu items added to a new "extension (sub-)menu" that we define is more reasonable. Is that what you want?

Making sure the JetPack API does something reasonable also makes sense, but I know very little about the relevant JetPack APIs.
The existing best-practice for pre-jetpack add-ons is to use overlays, I don't think there is an API call that exists currently to add menu items other than standard DOM APIs. So the choices for non-Jetpack developers add-ons seem to be:

* Fix overlays to work. This seems hard for the general case but possible if we say just wanted to create one single menu that was shared between both menu styles. That would require developers to switch to using that.
* Create a new API call for add-ons to use, but that assumes we can actually get developers to switch to using it.

Both of these require developers to make changes and both will end up restricting what developers can do in some way or other.

On the other hand if we do nothing then add-on developers have to cope with making sure they support different menu structures on different platforms which they have already had to do to a limited extent anyway as the menus differ between Windows, Linux and OSX. If a developer only bothers to develop on one platform I suspect they'll pretty quickly hear from other users (or even the AMO review team) that they have missed something and need to fix it.

We can't provide a magic bullet to solve this for non-Jetpack extensions, I think this would be better solved with docs and outreach and validation by the AMO reviewers. We should of course make sure that Jetpack is doing the right thing regardless of what we do for the non-Jetpack case.
I have little confidence in add-ons developers proactively supporting modern windows on their own, I'm mostly concerned that when users complain they will shift blame over to us, saying that we are making cross platform development too hard (to be fair, we are in fact making it pretty hard).  So I don't think angry users will by itself result in a change in developer behavior.  However, having the AMO reviewers check for supporting the Firefox menu seems like a reasonable solution, especially if they forward on the documentation on how to do it, and hold the extension in review until they address the issue.

>added to a new "extension
>(sub-)menu" that we define is more reasonable. Is that what you want?

It's important that the extensions are available in second level UI instead of third level.  A sub-menu off of the Firefox menu is going to be too slow and tedious for users to access.
(In reply to comment #21)
> It's important that the extensions are available in second level UI instead of
> third level.  A sub-menu off of the Firefox menu is going to be too slow and
> tedious for users to access.

How often do users really use these menu items though?  Most extension that I have seen just have a shortcut to their options.  A lot of extension whatever the purpose is automatically or through a toolbar item.  I can't see users really needing to change the options that often that an extra click is going to be too tedious and worth cluttering the beautiful minimalistic useful menu.  The cluttering (like the tools menu is now) is just clutter and not useful for anyone trying to find legitimate menu items.
(In reply to comment #22)
> (In reply to comment #21)
> > It's important that the extensions are available in second level UI instead of
> > third level.  A sub-menu off of the Firefox menu is going to be too slow and
> > tedious for users to access.
> 
> How often do users really use these menu items though?  Most extension that I
> have seen just have a shortcut to their options.  A lot of extension whatever
> the purpose is automatically or through a toolbar item.  I can't see users
> really needing to change the options that often that an extra click is going to
> be too tedious and worth cluttering the beautiful minimalistic useful menu. 
> The cluttering (like the tools menu is now) is just clutter and not useful for
> anyone trying to find legitimate menu items.

That was a slightly full of fail.

How often do users really use the current menu items though?  Most extensions that I have seen only have a shortcut to their options.  A lot of extensions do whatever the purpose is automatically or if the extension is used a lot a toolbar button is usually made.  I can't think of one extension that makes you access a menu item all the time to fulfill the extensions purpose.  I can't see users really needing to change the options that often that an extra click is going to be too tedious and worth cluttering the beautiful minimalistic useful menu.  The cluttering (like the tools menu is now) is just clutter and not useful for anyone trying to find and use legitimate menu items.
(In reply to comment #21)
> I have little confidence in add-ons developers proactively supporting modern
> windows on their own, I'm mostly concerned that when users complain they will
> shift blame over to us

I think you have too little faith in addon developers, and too much concern about these kinds of issues  reflecting badly on us (or even posing a problem for users) :) Sure is hard to objectively measure and quantify those things though! Dave's comment 20 matches my feelings pretty closely, and so I agree with his recommended approaches to addressing the problem (primarily developer outreach).
Blocking-. Per above comments, there's no magic solution for this.
blocking2.0: ? → -
Keywords: dev-doc-needed
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.