This is a subsection of bug 322705 regarding reordering of menus, context menus and options _only_. This is the first bullet point at http://wiki.mozilla.org/Firefox:3.0_Tabbed_Browsing#Required_Features Tab browsing preference changes should be filed as a separate bug. Patch coming up.

Changes: - File menu (new tab/window, close tab/window) - Context menu (open link in new tab/window, open frame in new tab/window) - Open location dialog when location bar hidden (open in new tab/window) - Bookmarks context menu (open bookmark/livemark etc. in new tab/window) - History context menu (open in new tab/window) - Preferences dialog (tabs panel) - Changes ordering of open_external preference to have the new tab option at the top. Note that this option is the current default. - Preferences dialog (tabs panel) - Changes ordering of 'Force links that opn new windows' preference to have new tab as the first option. This _doesn't_ change the preference. The default is still to not divert new windows. - Changes the ordering in the corresponding locale files to match the ordering in the app.

Comment on attachment 207891 [details] [diff] [review] Reorder menus, context menus and options to promote new tabs ahead of new windows Some random person using a bugmenot login added that to the list. (That doc is largely obsoleted and user-edited to death) I asked you to present an argument for changing longstanding behaviour (by the time we ship Firefox 2, we'll have had this order for well over 18 months for > 30 million users). You need to provide a rationale for changing this besides "just because its better" at this point. Please request review once you've actually done what I asked for.

Also, if you want to include some ASCII art or a mockup showing what you're trying to get to, you can throw that in here and use the swanky new "ui-review" flag! :)

Other browsers do it and tabs are used more than in the past since all browsers use tabs now was my thinking from the duped bug.

Yeah, I think we may want to consider this. Really think this is pretty trivial though

It's a UI change, not a bug, so it should stay as enhancement.

Over in bug 490507 mconnor suggests: >ordered on frequency of use rather than pseudo-arbitrary hierarchy I'm going to have to endorse the pseudo-arbitrary hierarchy (hm, doesn't seem that great when you phrase it that way). Adaptive context menus are really non-standard, surprising, but more importantly they don't give the user a direct path to the more effective interface (tabs). Trying to push users in the direction of the better way isn't pseudo-arbitrary, it's in fact very intentional.

I didn't mean it like that, yeesh. I meant that tabs are going to be used more, so they should be first. Instead of "under" window options because of the arbitrary hierarchy.

Since "Recently Close Tabs" menu in History menu is above "Recently Close Windows", can we imply that now tab gets higher priority than window in term of user experience?

I believe the two things that are at odds with this enhancement are historical UI on the one hand, and better UI with better parity on the other. It's true that it will take users some amount of time to adjust to a change in the ordering of the menu items, but it's better to do this now than later, if we all agree it's a better UI. If Firefox is still gaining in popularity (and I believe it is), the longer we wait on this, the harder it will be to make the change. I recently played with Chrome, and I very quickly got used to the ordering of the menus. I suggest pushing this enhancement through as soon as possible. It will slow people down briefly, yes, but ultimately it is what's best. I don't see any disagreement about that on this bug.

There's no wanted-3.7 or wanted-4.0 flag... It would be good if right-clicking a link then only required a very small movement to get to "Open Link in New Tab". I still use computers with 2-button mice.

Yup, agree that this is something we should do. Alex & Alex - if you're interested, this is a good first patch :)

however, assuming most mice have three buttons, and since middle click already opens in new tab, leaving the "window" action as the first action, allows fastest access to both actions. promoting the tab access is somewhat redundant, as it does not provide faster access to "tab", just slower access to "window". the main benefit seems to be discoverability.

Remember laptops and netbooks. While the driver software on some can be configured to support a middle click, it is not always the case.

And middle click is not a commonly used interaction for users, so it's not the best way for us to be making this decision.

Agreed. I /know/ about emulated middle click on my two button mouse (by clicking both buttons simultaneously), but I can't remember the last time I actually did it. And, even as a computery person, I've never owned a mouse with a middle click button...

As suggested by bletzner, the options menu preferences were not rearranged.

This might be crazy, but can this also be completed for Thunderbird? I doubt there's a similar bug, but changes like these seem like they ought to be coordinated so the two stay in sync.

Comment on attachment 441893 [details] [diff] [review] Patch v1 Punting to gavin, I am not currently an owner/peer for this code.

It the benefit to new (context menu) users here really great enough to be worth breaking muscle memory for existing users?

(In reply to comment #25) > It the benefit to new (context menu) users here really great enough to be worth > breaking muscle memory for existing users? That's what the ui-r+ means, yes. We've been promoting tabs over windows throughout the product, and it's my ardent belief that most right-clickers want new tabs more than they want new windows. Recent test pilot backs this up with data showing that New Tab is used 4x as frequently as New Window.

Also, as discussed last night, I think muscle memory here will be easily retrained.

(In reply to comment #27) > Also, as discussed last night, I think muscle memory here will be easily > retrained. Doesn't that go against the argument for changing the order then? ---- Opera, IE, Chrome and all mobile browsers that support tabs (Opera Mini, Fennec, etc..) have the open in a new tab option as the first option in the context menu. I know that is not a good enough argument but changing the order helps new users and users that switch from mobile to desktop Firefox browser easily open links into new tabs. The extra movement of the mouse over a context menu entry that is not used nearly as often as the one below it (open in new window vs new tab) really doesn't make much sense. Test pilot studies have proven that the open in new tab option is used a lot more by far than the open in new window.

Sorry, after posting that I noticed you said "retrained" not "retained" ;)

Comment on attachment 441893 [details] [diff] [review] Patch v1 >diff --git a/browser/locales/en-US/chrome/browser/browser.dtd b/browser/locales/en-US/chrome/browser/browser.dtd >--- a/browser/locales/en-US/chrome/browser/browser.dtd >+++ b/browser/locales/en-US/chrome/browser/browser.dtd >@@ -257,16 +257,16 @@ > <!ENTITY searchFocus.commandkey2 "e"> > <!ENTITY searchFocusUnix.commandkey "j"> > >+<!ENTITY openLinkCmdInTab.label "Open Link in New Tab"> >+<!ENTITY openLinkCmdInTab.accesskey "T"> > <!ENTITY openLinkCmd.label "Open Link in New Window"> > <!ENTITY openLinkCmd.accesskey "W"> > <!ENTITY openLinkCmdInCurrent.label "Open Link"> > <!ENTITY openLinkCmdInCurrent.accesskey "O"> >-<!ENTITY openLinkCmdInTab.label "Open Link in New Tab"> >-<!ENTITY openLinkCmdInTab.accesskey "T"> >+<!ENTITY openFrameCmdInTab.label "Open Frame in New Tab"> >+<!ENTITY openFrameCmdInTab.accesskey "T"> > <!ENTITY openFrameCmd.label "Open Frame in New Window"> > <!ENTITY openFrameCmd.accesskey "W"> >-<!ENTITY openFrameCmdInTab.label "Open Frame in New Tab"> >-<!ENTITY openFrameCmdInTab.accesskey "T"> > <!ENTITY showOnlyThisFrameCmd.label "Show Only This Frame"> > <!ENTITY showOnlyThisFrameCmd.accesskey "S"> > <!ENTITY reloadCmd.commandkey "r"> >diff --git a/browser/locales/en-US/chrome/browser/openLocation.dtd b/browser/locales/en-US/chrome/browser/openLocation.dtd >--- a/browser/locales/en-US/chrome/browser/openLocation.dtd >+++ b/browser/locales/en-US/chrome/browser/openLocation.dtd >@@ -2,8 +2,8 @@ > > <!ENTITY enter.label "Enter the web location (URL), or specify the local file you would like to open:"> > <!ENTITY chooseFile.label "Choose Fileâ¦"> >+<!ENTITY newTab.label "New Tab"> > <!ENTITY newWindow.label "New Window"> >-<!ENTITY newTab.label "New Tab"> > <!ENTITY topTab.label "Current Tab"> > <!ENTITY caption.label "Open Web Location"> > <!ENTITY openWhere.label "Open in:"> Why are you doing this?

(In reply to comment #30) > (From update of attachment 441893 [details] [diff] [review]) > > Why are you doing this? It just makes it a little easier in the future for people hacking to find since these will be in order of how they actually appear in the menus. I've created patches before where the strings were all over the place in the file and it just looked untidy and unorganized.

I almost filed another bug for this, but I think it can easily be covered here. I just noticed that in the History side bar, the first item in the right click menu is "Open." Can we remove this as well? It doesn't seem to have any purpose, and breaks with the rest of the menus. I only noticed this because I just recently started using/needing the history sidebar, and I've had to train myself to not click the first or second items.

Note that the current plans are for New Tab to appear above New Window in the new Firefox menu for windows vista and 7: http://people.mozilla.com/~faaborg/files/20100718-firefoxButtonDetails/firefoxButton-i4.png

(In reply to comment #34) > Note that the current plans are for New Tab to appear above New Window in the > new Firefox menu for windows vista and 7: So, is this a plan for the new firefox menu *only*? What about context menus?

Comment on attachment 441893 [details] [diff] [review] Patch v1 You need to update the "runTest" function in browser/base/content/test/test_contextmenu.html with the new order, it currently spews 31 failures due to your changes: TEST_PATH=browser/base/content/test/test_contextmenu.html make -C obj-ff/ mochitest-plain > failed | checking item #10 (context-selectall) enabled state - got false, expected true > failed | checking item #0 (context-openlink) name - got "context-openlinkintab", expected "context-openlink" > failed | checking item #1 (context-openlinkintab) name - got "context-openlink", expected "context-openlinkintab" > failed | checking item #7 (context-selectall) enabled state - got false, expected true > failed | checking item #3 (context-selectall) enabled state - got false, expected true > failed | checking item #10 (context-selectall) enabled state - got false, expected true > failed | checking item #1 (context-openframe) name - got "context-openframeintab", expected "context-openframe" > failed | checking item #2 (context-openframeintab) name - got "context-openframe", expected "context-openframeintab" > failed | checking item #10 (context-selectall) enabled state - got false, expected true > failed | checking item #10 (context-selectall) enabled state - got false, expected true > failed | checking item #0 (*prodigality) name - got "context-undo", expected "*prodigality" > failed | checking item #0 (*prodigality) enabled state - got false, expected true > failed | checking item #1 (spell-add-to-dictionary) name - got "---", expected "spell-add-to-dictionary" > failed | checking item #1 (spell-add-to-dictionary) enabled state - got null, expected true > failed | checking item #2 (---) name - got "context-cut", expected "---" > failed | checking item #3 (context-undo) name - got "context-copy", expected "context-undo" > failed | checking item #4 (---) name - got "context-paste", expected "---" > failed | checking item #5 (context-cut) name - got "context-delete", expected "context-cut" > failed | checking item #6 (context-copy) name - got "---", expected "context-copy" > failed | checking item #6 (context-copy) enabled state - got null, expected false > failed | checking item #7 (context-paste) name - got "context-selectall", expected "context-paste" > failed | checking item #8 (context-delete) name - got "---", expected "context-delete" > failed | checking item #8 (context-delete) enabled state - got null, expected false > failed | checking item #9 (---) name - got "spell-check-enabled", expected "---" > failed | checking item #10 (context-selectall) name - got "spell-dictionaries", expected "context-selectall" > failed | checking item #11 (---) name - got [], expected "---" > failed | checking item #12 (spell-check-enabled) name - got undefined, expected "spell-check-enabled" > failed | checking item #12 (spell-check-enabled) enabled state - got undefined, expected true > failed | checking item #13 (spell-dictionaries) name - got undefined, expected "spell-dictionaries" > failed | checking item #13 (spell-dictionaries) enabled state - got undefined, expected true > failed | checking expected number of menu entries - got 24, expected 30

Addresses Dao's comment in reference to the tests. I'm not sure what all the failures are for (once one fails to the other tests after start failing?) but I know this updated patch will at least fix: > failed | checking item #0 (context-openlink) name - got "context-openlinkintab", expected "context-openlink" > failed | checking item #1 (context-openlinkintab) name - got "context-openlink", expected "context-openlinkintab" > failed | checking item #1 (context-openframe) name - got "context-openframeintab", expected "context-openframe" > failed | checking item #2 (context-openframeintab) name - got "context-openframe", expected "context-openframeintab"

(In reply to comment #37) > Created attachment 458803 [details] [diff] [review] > Patch v2 Sorry, I forgot to set it as a patch. I thought we used to be able to change the content type after attaching something?

Comment on attachment 458803 [details] [diff] [review] Patch v2 Looks good, requesting approval2.0. Note that this has ui-r=beltzner.

Comment on attachment 458803 [details] [diff] [review] Patch v2 a=beltzner

>So, is this a plan for the new firefox menu *only*? What about context menus? That's this bug, right?

(In reply to comment #42) > >So, is this a plan for the new firefox menu *only*? What about context menus? > > That's this bug, right? This bug was to reorder menus that already included the option to open in new tabs or window. The firefox menu button only has an open new window entry so if a patch is created in the relevant bug to add the new tab entry then it should be coded to add the entry above the new window entry..

Yep, current plans are for the Firefox button to favor tab creation over new window creation (with tab being the item placed directly on the main menu). Sounds like we have all our bases covered.

It's in, so it's fine either way, but I don't think we would have held the release for this. blocking2.0-

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3pre) Gecko/20100724 Minefield/4.0b3pre I have also updated the following Litmus test for the File menu. Can't find other tests we would have to update. https://litmus.mozilla.org/show_test.cgi?id=10036

Can we remove "Send Link" from the page right click menu? It's already under "file>send link" in the menubar and the FF button. http://people.mozilla.com/~faaborg/files/20100718-firefoxButtonDetails/firefoxButton-i4-small.png

This change is a killer of muscle memory for one of the most common actions in normal browsing. I registered for Bugzilla just to request this be changed back (Bug 609172, originally titled "[Regression] Please Stop Destroying My Muscle Memory"). Some other suffering user had already beat me to it; and after hanging 27 days in limbo, my bug was marked as a duplicate of Bug 596930. Although the above-captioned bug has been closed, it seems wise for the 322736 record to reflect that at least some users are (very) unhappy with the sudden overturning of 6+ years of muscle memory.

Samuel, I know you're not happy with the change, but on the whole it's a good one that eventually needed to be made. Other browsers have the New Tab option first, and so it was confusing for many people that switch between multiple browsers. Ultimately, promoting tabs is a good thing, and it's important that projects can make breaks from the past from time to time to make improvements. For me, I found that within a week, my muscle memory had made the switch, and that I preferred the new ordering. I've been on your side of a bug before myself, so I know it can be frustrating, but I have to say this one makes sense to me, and really does feel like an improvement once you're a bit more used to it.

If we provide icons for the high usage items for context menus (see bug 611570 for the traditional menu bar), I think that will help a lot. Instead of reading text users will start to target the graphic to open in a new tab (or not target the graphic if they want a window).

This is like changing the clipboard paste shortcut in Windows from ctrl-V to ctrl-Insert in order to promote the use of copy-paste. (Newbie users don't understand why V is paste and Insert would be more logical for them!) I registered for Bugzilla just to comment on this issue since I feel that it is an unnecessary breaking change of millions of users muscle memory. Having a new window open (instead of a tab) after clicking on the *second* context menu option for links feels fundamentaly wrong. I switch between multiple browsers and OS everyday and the new menu ordering has really thrown me when I switch into the FF beta. I did a quick check of the behavior in other browsers, the following have "Open in New Tab" as their second context menu item: FF3, IE7, IE8, IE9b, Opera11, Safari5. These represent upwards of 90% of global browser usage. Google Chrome (approx 10% of global usage) has it as the first context menu item. I believe that the relative positioning of the context menu items in relation to each other is not important for muscle memory, it is their positioning within the context that we retain in muscle memory. I personally don't do a linear search through the context menu each time, so once I've learnt which item is "New Tab" I don't see (or care) if "New Window" is positioned above or below it... Most other browsers have "Open" as their first context choice, probably since most context menus in an OS have the default action as the first context choice (which FF doesn't offer at all in it's context menu for links). That way they have the "New Tab" option higher than "New Window" but "New Tab" is "muscle memory compatible" between FF and most others.

Yeah, this change is weird and unnecessary. I mean, even IE *shudders* has tabs now. Even someone using IE for the first time will find their own pro/cons of using tabs vs windows. Are Firefox tabs special or something that they need to be hyped specifically? And really, this is an uncomfortable change as well. The first time I opened a tab in v4, I didn't even notice the change, and was getting annoyed at what I thought were either my miss-clicks or a glitch. Now I find I'm having to LOOK at the context menu every time I go to open a link in a tab to make sure I click the right thing. And yeah, I'm okay for a couple minutes while I'm thinking about it, but then I'll have been reading something for a while, then go to open a link and it's *muscle memory -> new window opens -> "ARG"* This is one of those things that looks good on paper, but stinks in practice. I agree with Joshua's analogy.

I didn't see this bug report and reported it as well. I've been using Firefox for several years and don't like to see things fixed that never appeared broken to begin with. I don't much care how IE works. In fact, IE (At least version 7 which I have here at work.) starts with "open", then "open in new tab" and then "open in new window", so open in new tab is still the 2nd choice so I don't even really have to look at the menu. I've been using 4.0 for about a week now and I am still opening new windows by accident.

Wow, this is unbelievable- I filed a duplicate as well. I hope you guys have your bug closing skills ready. The only thing you did here is aggravate your loyal users. If this browser doesn't feel like home, I might as well move on to Chrome. They "promote tabs more" because of their shiny blue colors, so you're still losing that battle.