The browser's "File" menu contains a "New" submenu. Most of the commands in the submenu are for mail (hidden in navigator-only installs) and for composer. "New Navigator Window" and "New Navigator Tab" may be outside of the submenu, inside the submenu, or in both places. Each case looks silly in some way (for example, if everything is only in the submenu, the first item in the File menu is a submenu and a common operation is buried in a submenu). Each case confuses users' muscle memory because the "New" commands are always present, but are in different places or in a different order depending on the component. I suggest that we remove the New submenu, like we're doing for the Search submenu (bug 135204). "New Navigator Window" and "New Navigator Tab" would appear in the file menu in navigator. "New Message" and "New Folder" would appear in the file menu in mail, with "New Folder" grouped with the other folder commands. I don't think "New Blank Page to Edit" (redundant with Window->Composer) or "New Address Book card" will be missed. If "New Message" needs to be available from the browser (why?), I suggest moving it to the Window menu and calling it "Compose E-mail". Suggested by Michael Wardle in bug 121767 and by mpt in bug 135204 comment 7. For history, see bug 37537, bug 63133, bug 63134, and bug 135571.

I agree with moving New Window/Tab back to the main level and removing the New sub-menu, but only so long as the other components each have their own specific "New" commands at the top level, and not those of any other component. (The only New menu items seen under File should be those relating to the current component.)

Mailnews needs: New Message New Folder New Account New Address Book card (I expect users to often want to do that) That's enough to warrant a submenu IMO.

I don't know about this. new mail message is a reasonable action to want to take, if you have mailnews installed. Maybe we could not show the submenu if there is only the one option in it?

I use New Message a lot, but I suppose Send Link would be a workaround...

Wouldn't you just launch mail and click compose? That's two clicks, compared to 3 to access new message now! I don't understand those last two comments. This bug is in the spirit of splitting Mozilla up more cleanly, so that browser only shows browser options/actions, etc. KISS, right?

For new message there is CTRL-M...

Hi. I'm using version 0.5 (Build ID: 2002090913). In the File menu there is a "New Window" option (Command-N) and "New Tab" option (Command T). There is no "New" submenu... i.e. WorksForMe! :-) Thanks. Err... I would have marked it as such, but when I logged in it gave me an error, and now the WORKSFORME option is gone. Oh well, I guess I'll just leave a comment.

Irk. Ignore previous comment. I linked into this bug from a chimera bug (in which this is not an issue) :-[

uid is being phased out.

I think it is valid to remove the submenus in both Navigator and Composer, but as comment 2 says, Mail/News probably still needs the submenu as does Address Book. As Neil says in comment 4, you can still create a new message via File -> Send Page. Comments anyone? i.e. if a patch is made will it just get turned down?

->samir and jglick, i don't think we'd want this for buffy, right?

sairuh, and how about mozilla?

Huh? I know Buffy, but what the *heck* is Mozilla? Something like Godzilla in form of Homer's barkeeper?

before you do things like this, how about making sure everything is reachable? i can't find a way to add or remove tabs from the sidebar using the keyboard. suppose I wanted to solve this using an extension, the easy way would be to add file>new>tab. All my extension has to do today is overlay the new submenu. If you decide to flatten navigator and not mailnews (because say you decide 2 new-s are ok flattened and 3 new-s are bad flattened), then i'd have to create magic (lots of it) to *unflatten* the menu and create a new submenu. supposing someone else comes along and decides to extend mozilla navigator in some otherway. Perhaps they want "new (split) view" which would allow independent scrolling of a single document. My extension doesn't predict the possibility of that extension, and that extension doesn't predict the possibility of mine. So you end up with both of us doing the same magic and you can have any of the following: File New Window Open Location... [Someone browsing with tabbrowser removed] File New Window New Tab Open Location... ["Normal"] File New Window Tab Sidebar Open Location... [My extension installed] File New Window Tab View Open Location... [other extension installed] File New Window Tab Sidebar New Window Tab View Open Location... [One way both extensions could be installed] File New Window Tab View New Sidebar Open Location... [Another way both extensions could be installed] File New Window Tab View New Window Sidebar Open Location... [Another way with both extensions installed and tabbrowsing removed, yes notice that View wasn't written well and presumed tabbrowser existed] Or you could have: File New Window New Tab New Sidebar New View Open Location... which would really look bad when someone opens mailnews and gets File New> Message Folder... Account... Contact Open Message <-- does anyone even know what that does?? (I know now that i used it...) Without an architecture (and simply saying you're going to flatten the current system which happens to have a scalable specification removes any architecture) you invite problems.

Forcing an additional click on users for a *very* frequent action (I personally do that probably dozens (if not hundreds) of times daily) is too severe an effect for more theoretical arguments like extensions. If you want, make an additional New menu which only shows, if it contains something - extensions could hook up there, if you really want that. FYI, exactly this problem was one of the major reasons for me to decide for a browser (I don't remember which) in the 4.x days - IIRC, MSIE 4.0 had File|New|Window, and it annoyed the heck out of me. Beonex Navigator has the menu flattened in 0.8.x.

keep in mind, even if mailnews isn't installed we want to have "File | New | Message". It, like File | Send Page and File | Send Link and mailto: urls would just launch the default mail application. I don't think File | New | Message shows up for browser only installs. but that's a bug. see bug #144828 and http://www.mozilla.org/mailnews/altmail/index.html the reason is the overlay for that lives in the mailnews package, but that will change when #144828 is fixed. since File | New | Message is going to be there, and we have New Window and New Tab, I don't think we should be flatten the File | New menu.

Why do you want File -> New -> Message? If i want to create a blank message, i'll open my mail client and create a new message. if i want to do something relevent to the browser (click a mailto link, send a link to this page via email, etc) then i can do that from the browser. btw, what do you expect to happen if i have no email client installed at all? You may say that New Message is "useful", but then maybe i want to write a letter - should we then also include File -> New -> Word Processer Document (and so on). Anyhow, that's just my opinion. You are the Mail/News owner so you have final say (rightfully) over what goes in to that component, therefore (unless you change your mind:) the New menu will stay in Mail/News. As for the other components, i presume this isn't wanted there either? (in which case i'll mark this wontfix)

Um, Piers, you're not thinking of Chimera or some other browser-only product, are you? I actually have a vote on this bug, so you know what my opinion is, but "File -> New -> Word Processer Document" isn't a fair argument because Mozilla doesn't include a Word Processor.

I think that composing emails and reading emails are 2 equal tasks. Personally, I think that File|New|Message in the browser makes no sense, just as "File|Show New Emails for me" make no sense in a browser. (File|Send Link is different, because there's a relation to the browser.)

Erh, so ... I think it'd be okay to have "New Navigator Window" and "New Navigator Tab" in the File menu, and the other items in the "New" submenu. For Mail/News, "New Message" would be in the File menu, with the other items in the "New" submenu, etc. (i.e. put the most frequently accessed "new" actions in the File menu itself). I seem to recall however that this was how things were in pre-Moz1.0 versions of Mozilla, and then we did the big menu reorg. and moved all "new" things into the New submenu. jglick, do you recall what our reasoning for this was?

Never mind, just found the e-mail you sent on this issue. We talked about this issue (as part of the menu reorg) at various pixeljockeys meetings and found that it was less confusing if all the "new" items were grouped together, either in the top level menu, or in a "new" sub menu. Since the former would make the "File" menu too large, the latter was chosen. We're not going to revisit this issue, marking this bug wontfix.

>Never mind, just found the e-mail you sent on this issue. It was the topic of a pixel jockies meeting way back. Consistency of all apps vs each component implementing this differently. If we flatten the File: New menu, Browser has just two items, Window and Tab, but Mail has 3 and Address Book has 4 app specific new items, which makes the File menu sorta long. Originally (before we made this change, menu reorg), if i remember correctly, we had "New App Specific Window" in the File menu, but any additional app specific new menu items were in the New flyout with the other cross app New items. (For example, New Message was in the File menu but New Folder was in the New flyout). But, we saw this was a problem in usability studies. Some of the New items specific to the app were in the File menu while others were in in the New flyout. Users had trouble finding what they were looking for. Hence, the decision to keep all app specific New menu items grouped together. This lead to two options, keep them all together in the File menu itself, or keep them all together in the New flyout. Since Mail and AB have 3 and 4 app specific menu items, the New flyout seemed more logical for Mail and AB. If we wanted to keep all apps the consistent, Browser would need to follow as well.

2 arguments to consider: - UI studies don't cover routinated users who repeat actions hundreds of times per day. Also, I think the UI study didn't cover the case where the apps are inconsistent (flat for browser, submenu for mailnews), as proposed in this bug. - Some users don't care and don't want Mailnews, only the browser, and bugs like this make them suffer for Mailnews. This makes the argument of the "bloated" Communicator package valid :-(.

*** Bug 200053 has been marked as a duplicate of this bug. ***

For those that use File/New/stupid stuff, can't you use ctrl+m or type mailto:someone@nowhere.com into the url bar? Think the wontfix was dumb.

Did any one read the new roadmap http://www.mozilla.org/roadmap.html Here's a quote Another example of the high cost of app-suite integration is the inherently overloaded and complicated user interface (just one example out of too many: the File / New sub-menu). The target audience of the suite was never clear, and seemed to shift back and forth with prevailing business- and voluntary-contributor-driven winds. Hyatt's blog is an effective summary of the case against this approach. Simply put: great applications cannot be managed as common land, with whoever is most motivated in a particular area, or just the last to check in, determining the piecewise look and feel of the application. Doesn't anybody agree?

Sure, lots of people agree, the problem is some (lots?) people disagree as well. Also in the roadmap, they mention that they aim to keep a high-level of integration for those who want it - they want to please both schools. Personally, I think the managability is pretty important. If you can separate things out, it makes it easier to keep responsibilities clear and manage projects separately - especially as open source.

I don't really understand the new roadmap, but I think it says that Mozilla won't be a suite anymore. So if it's not a suite, should the submenu be removed now that the roadmap wants change? Am I interpreting the roadmap wrongly?