"Open link in new tab" is the first item on the link context menu. It should be just below "open link in new window", or hidden until the user selects "tabbed browsing mode" in prefs.

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

How about this: If "Open tabs instead of windows for middle-click or control-click of links in a Web page" is turned on in prefs, Open In New Tab is at the top, otherwise Open In New Window is at the top.

Finally found this bug after looking for 15 minutes. Updating summary to make it easier to find by having both new window and new tab. I'd just as soon have either a tab mode or a window mode, so like the reporter I'd suggest hiding the tab item until tab-click is turned on. I never use tabs and don't intend to. I don't see the point of having both in the context menus--it just slows me down. What's the point of picking each time? Are there really people that use both? In any case, the default behavior is new windows, so it should be the top context menu option.

There are quite many people who use both. But yes, the top option should imo be the default one. Which is "open link normally", not either of these two.

I think the order needs to be based on user preference in some fashion (as per comment #2), otherwise there will always be some group disagreeing with its current status (and filing / reopening bugs). Boris: I think that "Open Link Normally" may be confusing to people, whereas "Windows" and "Tabs" are less so. Actually, to be honest, it's confusing to me. Isn't opening a link normally the same thing as a left-click which, as far as I know, is always loading the page in the current window? And, if so, why wouldn't you just left-click in the first place to achieve this?

I think the phrase you're looking for is "Open New Whatever". :)

in the spec, [Open Link in New Tab] is above because it was felt that a) it should be on by default to better promote the feature's value and increase its discoverability; and, b) because we want to emphasize tab use over window use. * Not * meant to replace window use, but merely to accompany it, as a higher or equal frequency alternative to windows. I am willing to bank on the majority of tab users will be 'combo' users - making use of tabs when it makes sense, and making use of windows when it makes sense. We are still open to suggestions on this, but hopefully more insightful than, "i like windows better than tabs" (or vice versa). either way it's not an easy call, but i feel that by promoting tab browsing in this way, we're showing off our advantages over tabless browsers such as IE. [Open Link] is the default item, and should be the topmost item (as indicated in spec)

> Isn't opening a link normally the same thing as a left-click which, as far as I > know, is always loading the page in the current window? And, if so, why > wouldn't you just left-click in the first place to achieve this? 'open link normally' was a description of the item, not suggested text. The text would be [Open Link] as Marlon says or maybe even just [Open] On Windows it is the convention that default action performed on left-click should be in the context menu, the first item, bolded, and separated from the rest of the context menu by a separator. On Mac it is a necessity that the default action performed on left-click appear under the cursor when the context menu pops up on click-hold (that way click-quickly and click-slowly-which-triggers-context-menu do the same thing). On linux there is no convention (surprise).

"Open Link" and just "Open" are no good -- neither has any implication of new anything, window or tab, so the assumption would be that they would open something (what?) in the current window/tab.

> we want to emphasize tab use over window use I'm interested in understanding the reasoning here. And if this is the case, why didn't the File-New submenu change to have Navigator Tab first as well? Tabs have not had the same UI and testing focus as new windows and have a slew of bugs related to them. Emphasizing tab use is a poor decision if you ask me. UI should not be designed around showing off new product features. > I am willing to bank on the majority of tab users will be > 'combo' users - making use of tabs when it makes sense, and making use > of windows when it makes sense. How exactly would a user determine which "makes sense"? Randomly? I don't want to make this choice every time. Even in the combo-user case, it seems fairly clear that users will have a preference for their typical choice. It would make a great deal of sense to me to have menus reflect that preference. The closest pref we have now is the middle-click tabbed browsing option. If it's set (or create a more obvious pref) put Open New Tab first. If not, put it second. Boris and Marlon, Open Link as the first context menu item is bug 64749. Let's not rehash it here.

Tim, i think you've mistakenly assumed that tab users are exclusively tab users and vice versa for windows. this is not the case. the scenarios for tab browsing were addressed such that tabs fit within the windowing paradigm seemlessly. so it would be more accurate to say there are: combo-users or exclusive windows-users. the case for combo-users is more closely identified with the model for the contextual menu user, which explains its emphasis there. My goal is to follow suit in the main menus, however, main menus are a pretty touchy subject right now. however i am pushing on that one.

IMO the order of "new tab" and "new window" should be the same in the context menu as it is in the main menu (under file -> new). Using the context menu for opening links creates an automatism that's broken whenever you use the menu for opening a new window|tab.

I think everybody's pretty much in agreement that the New Window/Tab order should be the same in both the main menu and the context menu. As Marlon says in comment 11, he's trying to get the main menu order to change to come in line with the context menu order. (Then at least they'd be the same, even if the order itself is in dispute.) Personally, I think that the order in both should be controlled by the tab browsing pref as mentioned, but the main point is that they should be in the same order, regardless of what that is.

> On Windows it is the convention that default action performed on left-click > should be in the context menu, the first item, bolded, and separated from the > rest of the context menu by a separator. Incorrect. The convention is that if the default action is in the context menu, it is bolded. Not necessarily the first item, not necessarily with a separator below it, not even necessarily in the context menu. In RFC speak: The default action MAY be included in the context menu. If it is, it MAY be the first item, it MAY have a separator under it, and it MUST be bolded.

for reference to those of you searching the windows UI for a case where the default action is not the first item, isn't set off on both sides by seperators, but is bolded, (w2k) start>settings>network connections>{context menu for}any connected connection. what you'll get is something like: Disable/Disconnect Status (bold) - Create Shortcut Delete Rename - Properties Sort by Name If you're in a file explorer, sort by name won't be there. if you do it in the tray, you only get: Disable Status (bold) - Open Network and Dial-up Connections Note that for a disconnected/disabled connection the first item will be the default as Connect/Enable. Oh, you can also force an item other than open to be the default HKEY_CLASSES_ROOT\object\shell\(default) = someverbotherthanopen In w2k, you can make a shortcut to a program default to runas by checking the box in properties, so if you right click it, runas will be bold and not the first item in the menu. This comment composed in nc4 embedded in wordpad.

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

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

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

By selecting "tabbed browsing mode" in prefs means unselecting "hide the tab bar when only one tab open"? If in context menu "open link in new tab" is to be hidden if tab bar is hidden : 1) user may have no knowledge of tabbed browsing to be possible 2) I want tabbed browsing in the same way as new window, but without going to prefs 3) forcing tab bar to be visible for "open link in new tab" visible will force page display area to be reduced _always_ 4) User is not allow to choose, mozilla does it for him. (wasn't this the Microsoft way?)

I mostly like the new menus, but this swap is *very* annoying. I hate tabs, but now I keep opening them by mistake, making me hate them even more. A checkbox to hide "open in new tab" would be much appreciated.

I don't understand why the first item of the context menu should be the same as what happens when i click on a link with some button. If I open the context menu I do that exactly because I can *not* achieve an action by simply clicking a button. So if I've configured to open new tabs on middle click (because I do this more frequently than opening new windows (yes I'm one of those combo-users)), I want the "open new window" item at the top of the context menu so that I have it right next at hand. And vice versa. By the way, the default action in Windows (that one which is usually bolded) is triggered by a double click, not by single click. Therefore I don't see such a direct relation to the handling of a web browser. Furthermore I agree with comment #10 in that usability should not be impacted just to advertise product features. I think whoever opens a context menu will be able to read more than the very first item. Mozilla advocates on the web do much for advertising anyway, and tabbed browsing is one of their most striking arguments.

One more argument in favor of fixing this bug: Placing "...new tab" above "...new window" breaks several years of user motor memory. A little right-click, a tiny jog to the right, and violia. Instead, the application behaves unexpectedly: instead of the new window appearing, the user sees some kind of strange and unfamiliar tab doohickey. Combine this with another bug that breaks motor memory (bug 89308) and Mozilla's usability dips toward zero for folks who open lots of windows. It's not a matter of "default" so much as N4 parity and ingrained user behavior. In terms of all the controversy over which pref should do what, my very own personal ideal would be to have one pref somewhere which allows the user to say "Never show me tab-related UI nor open any tabs."

The view of pixeljockies is that the context menu order should change (to match the main menu order, and IMO the sane order. ;-) If one of the people who's been discussing how nice it would be to have this fixed would care to knock up a patch (http://www.gerv.net/software/patch-maker should make this a trivial exercise) then that would be great. Gerv

This seems to work.

This patch updates the order in the 'This Frame' submenu. Assuming it works at all.

I was initially puzzled by the change in 1.0 RC1 too, but after one week of using the browser, I've fully adapted and would never want to go back. In most cases when you want to use right click->new window (e.g. when browsing a complex news site, using a message board), opening a tab is the better choice to do. Of all the right clicks on links I've done so far, at least 90% of them were going to open a new tab, and not a new window.

> opening a tab is the better choice to do. That is *highly* debatable since it depends utterly on the user wanting a tabbed interface in the first place. I don't. I have good reasons for that -- which I'll spare everyone the ranting about -- but fixing this comes down to the simple issue of the UI working according to the "principle of least surprise," regardless of the desirability of tabs in the first place. "Remove or hide tab functionality completely" is a subject for a whole 'nother bug. Thank you, Alex, for the speedy patching.

Anyone feel like reviewing attachment 81800 [details] [diff] [review]? And does a patch this small need a super-review?

Comment on attachment 81800 [details] [diff] [review] May as well cater for frames too r=bzbarsky This absolutely definitily needs sr. From one of ben, blake, jag.

Alex, every patch needs super-review; except if the code is not part of the build.

Boris: thanks for the review. Christian: thanks for the clarification. I asked because some bugs, e.g. bug 122108, have got checked in without an sr. Guess they must have just slipped through the net. Blake, can you give me an sr?

Alex: hm, that surprises me, but I suppose it was because it was only a wording change... so review of jglick was enough...

Alex/Christian: Wording-only and comments-only changes have an auto-sr=brendan.

Jonas: Apr 03 22:38:29 <brendan> biesi: no auto-sr= from me for anyone Apr 03 22:38:37 <brendan> i give auto-sr= for wording changes to wordsmiths i trust also, that bug was checked in without any mention of sr in the checkin comment.

<quote author="Gerv" source="bug 53764 comment 23"> Comment changes only have an auto-sr=brendan. </quote>

>In terms of all the controversy over which pref should do what, my very >own personal ideal would be to have one pref somewhere which allows the >user to say "Never show me tab-related UI nor open any tabs." Strongly seconded!

Comment on attachment 81800 [details] [diff] [review] May as well cater for frames too sr=jag

I could accept comment #2, but I don't want to be forced to have Open in New Window above Open in New Tab with no way to change it; new windows take longer to open, are more difficult to manage and switch between, and are a pain in general; I definitely want Open in New Tab at the top. I don't mind if that's a pref. And I don't care what the default is; I can change the setting without complaining. But New Tab is used so much more freqently than New Windows (25:1 or more) that it makes NO sense whatsoever for New Window to be listed first. > Are there really people that use both? Yes, there are. For now a _lot_ of us do, because after about 20-50 tabs (the number depends on your resolution and stuff) you have to open a new window to work around a couple of outstanding bugs. Even after that stuff gets fixed, some people use separate windows to keep distinct things distinct; for example, a Google search for one thing in one window, with all the results in various tabs, and Bugzilla search for something else in another window, with the bugs and attachments and other related things in various tabs. Bookmark Groups users also find separate windows for each group convenient. In other bugs, there are people asking for the browser start page (formerly "home page") to be a folder, which can contain arbitrarily many bookmarks (each opened in a window) and groups (each opened in a window, with one tab in that window for each item in that group). All of which is to say that people use both. But this bug is about order, not the ability to hide undesired things. You can hide things with CSS settings (display: none), although this is not end-user-friendly, and anyway that should be a separate bug. > On Windows it is the convention that default action > performed on left-click should be in the context menu, > the first item, bolded, and separated from the > rest of the context menu by a separator. Three observations about this: 1. This would make it much more difficult to reach "open in new tab", which is a _very_ frequently used feature. A definite usability loss. 2. It (putting "open link" on the context menu at the top) breaks with all existing browser conventions of which I am aware; Mozilla is a browser, not an operating system or file manager, so browser conventions ought to be at least as important as Windows explorer.exe conventions. 3. This bug is about the order of existing entries, not about adding a lot of extra bonus entries. That if anything should be filed separately, although I personally would consider it a strong WONTFIX candidate. The fourth observation (that your statement about the Windows UI is untrue anyway) has already been made. > Emphasizing tab use is a poor decision if you ask me. It is a _substantial_ performance win. But I think my main concern is that people who obviously want to use tabs (say, those who have checked the various "open new tabs instead of new windows" prefs in the tabbed browsing prefs panel) should be able to easily do so. If not checking the tab prefs results in new window being first, I can live with that, but I want a way to get new tab listed first. Ctrl-clicking involves another hand, which is inconvenient at best, and while I have a middle button at home, I don't have one on every computer I ever use Mozilla on, and some people don't have them at all. The convenience of the current placement of "Open Link in New Tab" is a big usability win. I want to be able to get that placement. I don't mind having to have a pref checked to get it, but I want it. Should I file that as a separate bug?

> But New Tab is used so much more freqently than > New Windows (25:1 or more) that it makes NO sense whatsoever > for New Window to be listed first. So? For me it isn't - I never use Tabs, unless I accidently hit this damn option since it's at the top of the context menu. This is why it extremely annoys me that this option is at the top. This should _not_ be a pref, imho. Maybe a pref would be useful for "Never show me Tab-related UI", but this feature doesn't deserve one.

Has this already been checked in, seeing that it has r= and sr=?

> Has this already been checked in, seeing that it has r= and sr=? No, not yet. I'm trying to get approval from drivers to get this checked into the 1.0 branch first.

Adding custrtm-; no impact on customization.

fixed on trunk.

I didn't realise this had been checked in. I'm pessimistic about this getting in 1.0.1; drivers have rejected it from the branch once before.

I personally disagree with tabs being listed below windows, however I'm glad that this fix was implemented; not because tabs are below windows, but because there's finally consistency between the context menus and main menus. (In the future, if this is to be changed, I hope that it is changed in both places rather than in just one or the other.)

If you use tabs frequently -- which you probably do if you use tabs at all -- you want "open in new tab" to be the middle-click action. So then, you want "open in new window" to be the first in the right-click menu -- otherwise, you've got one function taking up two redundant top positions.

I don't want to argue the point - but what about people who have no middle mouse button? Or, those who want the middle button to do something else?

> but what about people who have no middle mouse > button? Or, those who want the middle button to do something else? Hold down Ctrl and click the link.

Yes, I do that. But it means you have to use the keyboard at the same time. It's convenient to be able to do everything with JUST the mouse. Okay. <sigh> I'm not going to debate this, especially since I'm not saying everything that hasn't been said before.

FYI, tabs really shine when used with open-in-the-background (bug 144851 which is also WONTFIX due to a similar desire to accommodate old habits). I have found "Open Link in New Tab" (as first context-menu-option) in conjunction with open-in-the-background as the best combination, to the point of warranting to break old habits. The combination makes reading a page with numerous items easier as several tabs can be opened in advance. It takes a two passes process, the first being to rapidly cruise over the page (or its visible area) to tab the links of interest, but once this new habit is developed, tabs become impressive and useful. I didn't appreciate fully the tabs until I discovered open-in-the-background and settled in the new habit. From such a perspective, "Open Link in New Tab" as the first option is more efficient, although it causes surprise at the beginning.

Why is this bug marked NEW when it appears to have been checked in? Very annoying this morning when I updated from 20020529 to 20020605. I had habituated to a "right-click-twitch-hand-release" reflex motion that backgrounds a new tab, and suddenly I'm popping up new windows! It's going to take me the rest of the week to stop doing it, and from now on I'll have to actually LOOK at the context menu. Where can I vote to ask that Tab comes before Window in both menus?

Marking FIXED since this is fixed on trunk. Branch checkins are tracked with keywords, not with the bug status.

Opened bug 149297.

Is there an easy way to change this in the code, for those who prefer tabs on top? Perhaps a line or two?

Whether you like tabbed browsing or not, the fact is that Mozilla 1.0 shipped with 'Open link in new tab' at the top, so I think it should stay that way for 1.x. If you change this for 1.1, all the people who were annoyed at first, but then got used to it, will be annoyed again.

Excuse me, but it seems to me that the majority of the comments here is in favour of the 1.0 order (first tab, then window). In view of this, then why was this change made? Please don't say "menu consistency". Menu consistency would have been preserved if the Tab item had appeared first in the context menu _and_ in the menus too (as it should be, IMHO). Also, please don't say "because 4.x had 'open link in new window' as the first context menu item". 4.x did not have tabs, and tabs are one perhaps *the* single most visible advantage that mozilla has compared to over 4.x and most other browsers. I think this is a step backwards from 1.0, and it changes what 1.0 users will have gotten used to. It should be backed out. Does anyone agree with me?

Personally, I'm strongly in favor of restoring the context menu to the classic "New Window" above "New Tab" arrangement, not only for consistency with the current version of IE, Netscape, and every Mozilla beta over the past two years, but because a new window is so much more useful than a new tab (e.g. you can view pages side-by-side). Too many designers have developed their interfaces with a priority on showcasing new features (such as the tabbed interface), instead of usability. Since some of you have used this as a reason to place "Open in New Tab" on top, I would like to suggest that this is not such a great motivation. The only time I ever open a new tab is when I *meant* to open a new window. Although the new context menu arrangement has been in effect for more than two months, and I still haven't trained myself to use it properly without thinking first. Perhaps ten years of motor memory should take precedence over "discoverability." I hate tabs. Ideally, I'd like a way to disable the tabbed interface entirely and hide all related menu items.

D.A. Karp, what you're saying is that you hate tabs and don't want to use them, so the Open in new Tab menu is useless to you. I have two comments about this: 1. Why not use middle-click or ctrl-click to open in a new window? It's faster than using a context menu, even if you have motor memory. 2. You probably hate tabs because you've never really tried to use them. They complement windows nicely: you can group related pages as tabs in a window, and unrelated pages in new windows. Tabs are faster, take up less screeen space, and don't clutter the taskbar. Plus, "load links in the background" is a real time saver: when you open a new link, you don't have to go back to your current window, you can just go on reading. I didn't like tabs either, but now I'm hooked. You should try using them.

Lorenzo, you start with the wrong assumption that everybody will like tabs once they get used to them. However, this is not true. Tabs prevent you from easily switching to the correct browser tab, you need two clicks now instead of one (one for the window, one for the tab). Also, you loose overview on the windows you have open. Grouping related sites together isn't important, at least for me. I can find them by looking at their titles. >1. Why not use middle-click or ctrl-click to open in a new window? It's faster >than using a context menu, even if you have motor memory. Using, e.g., Microsoft's Intellimouse software, this is not possible. >2. You probably hate tabs because you've never really tried to use them. Uhhh. This is a _very_ dared statement. > Tabs are faster, That is a seperate bug. > take up less screeen space, No, they take up more, because they require the tabbar. > and don't clutter the taskbar. Which is why I dislike them. > Plus, "load links in the background" is a real time saver: That should be implemented for windows too, the concept isn't tab specific. By the way, D. A., this bug is fixed, so that "open in new window" is now at the top again.

Please, can we keep the tabs advocacy (either for or against) out of this bug? Whether tabs are good or not is a tangent.

It seems to me it is necessary to consider the merits of tabs and windows to reach a conclusion as to which should be favored by the most conveniently positioned item in the context menu. It is unhelpful to discourage discussion of the merits, or to refer vaguely to alleged advantages of tabs or windows, without explaining what advantages and why the point favors one position or the other on this bug (as in some earlier posts). "Open in New Window" has at least 3 objective advantages over "Open in New Tab". (1) The tab bar takes a significant amount of window space; a new window does not take any additional screen space. (2) Using separate windows allows navigation among them with the convenient Alt + Tab, while tab-to-tab requires using the mouse. (3) Most of those who use tabs at all use both tabs and multiple windows, while others use windows only. Therefore "Open in New Window" is what is useful in common to both groups, while "Open in New Tab" serves one group only. My vote is with those who have requested a way to turn off all tab-related UI (and if you turned it on, you could have "Open in new tab" on top). Seems to me that would suit just about everyone. But if we can't have that, "Open in New Window" is second-best.

Either leave it alone or come to a conclusion quickly. I don't care which way it is, as long as it's consistent. Every time I use a different build, it seems like it's switched around again. Just pick one and stick with it. Once you get used to it, it doesn't really matter which way it is, as long as it stays that way.

Guys, this bug is fixed. Open in new tab is now below open in new window. Please stop adding comments about how much you feel that this should be fixed or how you think a conclusion should be made; a conclusion /has/ been made and this bug /is/ fixed. If you still wish to debate which item should be first, or if you feel there should be a pref for it (there shouldn't), or if you have any other suggestions, please take it to the netscape.public.mozilla.ui newsgroup.

adding adt1.0.1-. Too late to change for the branch.

> Guys, this bug is fixed. Open in new tab is now below open in new window. > Please stop adding comments about how much you feel that this should be fixed > or how you think a conclusion should be made; a conclusion /has/ been made > and this bug /is/ fixed. This may detract from the developers working on something else; so be it. But I want to make my opinion known (as have many others here) that I feel that the fix *is* the bug. If I've got tabbed browsing enabled, it's because I don't want any new windows open, and if the "new windows" option has gotta be on the context menu, it damn well shouldn't be first. A similar issue (I'll probably open a different bug report for this one) is that I want the option in the Edit->Preferences to make a link that defaults to opening in a new window to instead open in a new tab....because like I said...if I'm doing tabbed browsing, its because I don't want new windows opening up on me....

FYI, drivers do not want this "fixed" on the 1.0 branch -- we do not believe that significant UI changes are appropriate there, and menu item reordering counts as significant. BTW, I sympathise with those tab users who do not want open-new-window to be first. Did anyone file a new bug asking for a better solution than what was done for this bug? /be

v