Closed Bug 149297 Opened 22 years ago Closed 22 years ago

Open link in Window / Tab should be consistent and by user preference or tab browsing use.

Categories

(SeaMonkey :: Tabbed Browser, defect)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: jasonb, Assigned: mpt)

References

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0+) Gecko/20020603 BuildID: 2002060305 Several bugs have already been filed (some resolved, although not without a lot of disssension) that address components of this one, but none that address the whole issue. Since there is endless debate over the order in which New Window / New Tab should appear in menus it's obvious that no static order will ever be acceptable. The solution has to be one of either another user preference, or an implicit preference based on the Tabbed Browsing preference selections (mainly "Middle-click or control-click of links in a Web page"). Further, I want to say that whatever order is decided on HAS to be consistent - the order displayed in the context-sensitive menus should be the same as the order display in the File menu. (With the checkin for bug 135250, at least on the trunk, the order is now finally consistent, solving one "sub-problem" here.) Since adding more preferences should be avoided, I believe that the already existing Tabbed Browsing preference should be leveraged in order to offer an implicit preference in this case. (In the majority of cases, if this preference is selected the user will be using tabbed browsing.) This is an idea that has already been discussed elsewhere and received favourable opinion: 1. If "Middle-click or control-click of links in a Web page" is not checked the menus should be: File / New / Navigator Window File / New / Navigator Tab Open Link in New Windows Open Link in New Tab 2. If "Middle-click or control-click of links in a Web page" IS checked they should be: File / New / Navigator Tab File / New / Navigator Window Open Link in New Tab Open Link in New Windows But, whatever the final solution, there are, again, two points that should be kept in mind: 1. This is an individual decision and there is too much difference of opinion to hard code the order one way or the other. (NB: Please, I don't want debate on which is the "better" order, unless there is some reason, other than personal opinion, for why it should not be up to user preference.) It needs to adjust to the user's browsing style. 2. The order in which Window / Tab appears needs to remain consistent between the File menu and the context menus. One should not be altered without similarly altering the other.
This suggestion seems to be the exact opposite of what makes sense. The top option should not duplicate the middle-click action. I used tabs most frequently, but occasionally want a new window, so I have open-in-new-tab as middle-click, and I want open-in-new-window to be the top of the right-click menu. Conversely, if I used new windows most frequently, I'd want that as the middle-click action and the top menu choice to be new tab. My guess, though, is that the UI people will veto changing the menu order around, as it seems like a strange side-effect from an option which is only tangentially related.
On the contrary, from all comments I've read on the subject, those who use tabs most often want the top-level context item to be "New Tab", while those who don't use tabs want "New Window" as the top-level item. (That's my personal experience, and also what I've seen other mention.) I was only trying to accomodate the usage pattern I've seen communicated so far. You're the first person who's mentioned otherwise. If there are enough people "ringing in" who indicate they use it as you do, then leveraging the existing Tabbed Browsing preference may not be the wisest course after all, and adding another preference to accomodate this should be more seriously considered. As I had meant to indicate, however, whatever method is used to determine the order, it should still be based on individual user browsing habits, in one way or another.
Perhaps most people who use tabs do not use the middle mouse button. "Ringing in" or not, people who *do* use that button shouldn't be penalized. But I suspect this is all moot, because I doubt that there will ever be an option that moves menu items around. The answer will be "make your own mozilla-based browser".
I'm certainly not trying to penalize anybody. I'm trying to come up with the best solution for everybody involved and your input has certainly helped broaden the picture a bit as to user preferences. As to refusing to move menu items around - "they" <grin> already have. Even though they've said that they want to list Tabs first, they've still allowed a patch for bug 135250 that list Windows first. So there's obviously some room for accomodation here. (Unless you mean that the branch will never be changed, only the trunk.)
Summary: Open link in Window / Tab should be consistent and by user preference or tab browsing use. → New Tab and Open Link in New Tab should be at top when a pref is set
The first need is to make configurable the relative placement of the "new tab" and "new window" menu items. The second need is to keep the middle-click action (and associated actions) consistent, yet configurable. Creating a new preference seems justified in this case. There is room for associated UI under Preferences | Navigator | Tabbed Browsing. One way, windows go over tabs in both menus. The other way, the reverse order. While it could change in the future, for now the default will apparently be windows over tabs. The new preference would keep the middle-click action very configurable. The default action for a middle-click should open a new window. That would be consistent with the default relative placement of the menu items, as above. The user could still configure middle-click separately. This allows a good amount of user control.
Summary: New Tab and Open Link in New Tab should be at top when a pref is set → Open link in Window / Tab should be consistent and by user preference or tab browsing use.
> While it could change in the future, for now the > default will apparently be windows over tabs. Although that is the default in the File->New menu, it is not the default in the right-click context menu. Personally I do not care which is default, but it should be consistant between the two menus and the order should be configurable via preference panel. Of course, ideally, I would like to see the user preferred option return to the top level of the File menu, but that is a different bug.
> Although that is the default in the File->New menu, it is not the default > in the right-click context menu. It is now in the trunk - just not in the branch.
Jason -- I didn't mean that the menus are frozen forever. I meant that the concept of having an option which changes menu ordering (or options) is likely to be rejected as damaging to UI consistancy -- even if it's something that reasonable people disagree about. See bug #136665 for example.
How about a simple line in pref.js (or whatever the user prefs file is)? It will resolve the problem sufficiently and quickly for us, if not perfectly, and let us turn our resources to something more needed by the millions of other users.
New Tab should be first in both menus, not sure when the troops will come around to this idea, if ever. Another idea - (not sure if this has been mentioned) what if the New Tab items were only available when the tab bar is present? Since in commercial we are going to have tab bar on by default, the user can decide to close it and lose most reference to tabs until he/she turns it back on in the view menu? (again sorry if this has already been talked about) That way we don't disturb tab-haters, and we give tab users the most appropriate UI. Tabs are simply higher frequency items, and they are subsets of windows therefore they should be at the top.
Marlon (and everyone else too): Please refrain from commenting on what order New Tab / New Window should appear. Doing so will just open up another heated debate, which this bug was filed to prevent. (So that we can accomodate both sides and satisfy everyone.) Thank you. As for New Tab only appearing when the "Tab Bar" is shown - that's a new one to me. I've never heard of this tab bar before. Can somebody point me to where it's being discussed? I'm not sure if that's a good idea either (although it's a possibility). I like having free real-estate and even if there were such a thing as a tab bar I problably wouldn't view it - even though I'm an avid tabbed browsing user. I'd prefer to keep have the read-estate free given that I could perform all tab browsing features via existing mouse, keyboard, and menu functions. (Unless there will be features on the tab bar that will only be available there?)
I believe marlon is referring to the tab bar that pops up when you have more than one tab open (it is always there if "Preferences->Navigator->Tabbed Browsing->Hide the tab bar when only one tab is open" is not set). Not a bad idea, although people who do use tabs would probably need to always have the tab bar there (unsetting the preference above) so that if they do want to open a new tab, they can do so from the context menu. Of course, I keep the tab bar always on and open new tabs with a middle click, so it's not an issue for me...
gstoll -- would you agree with me that since "new tab" is middle-click, it'd be awful to also make it be the top right-click option?
Matthew: hmm...After thinking about it for a minute, it shouldn't really matter. Here's why: Since middle-click can only be set to open a new window or open a new tab (correct me if I'm wrong), then people will presumably set that to be whatever they do most often. So, the context menus would probably be used for only their least common choice. So, according to this, the least common option should be on top, which is a bit odd. :-)
yeah, exactly. :)
Umm...sanity check? Most people don't HAVE a middle-click.
All *nix users do. And on win32, the scroll-wheel almost always functions as a middle-click -- aren't those mice the norm these days? Even if you don't have such a mouse, you can get one for $20 or so. And if you're on MacOS, you're pretty used to keyboard+mouse actions anyway. Why break Mozilla for everyone else just because you're missing increasingly-common functionality?
The point of this bug is to provide a solution that works reasonably for everyone (hence basing it on a preference or implicit browsing use). Assuming that everybody has a middle mouse button, or should run out and buy a new mouse that does have one if they don't just to address this, is I believe unreasonable. Whatever solution is provided shouldn't be predicated on this assumption. (BTW: It's not any more true that Unix/Linux users have a middle mouse button than that Windows users do. A good number of Unix/Linux users have two button mice and I'm sure that some of them choose not to enable 3-button emulation. Also, any Mac user is being left out here.) Tab bar idea: Okay, I know what's being referred to now. I'd been thinking along the lines of a tab toolbar. I don't have the tab bar set to always on. How would I invoke the *initial* tab browsing (going from just one site to two) if I need the tab bar to exist in the first place - which won't when I only have one site open? Again, I think we're back to a preference - only now it seems like "two" preferences: [ ] Show New Tab / Open Tab first ( ) in menus. I'm not entirely happy with that wording, but the general idea is that this would accomodate those who want to set the order *and* those who might not want to see them AT ALL. (The question of the default would be decided later.)
After further thought, I would be ready to endorse Marlon's suggestion in comment 10 *IF* we had the ability to collapse the "tab bar" as we do with proper toolbars. That would alleviate my objection to having a single tab open, since all I would see (screen-wise) would be a thin line at the top of the screen as per other collapsed toolbars. Even better would be if we could "upgrade" the existing tab bar to a proper toolbar, accessible via the View menu with appropriate collapse / expand functionality. I've opened bug 150379.
I'm going to weigh in on this even though the appropriate response should probably be "off to newsgroups" I didn't even know about the tabbed browser function until 0.9.9 when my right-click new window motion created a new tab instead. I discovered the feature *because* of its location. Without debating whether or not we should "promote" its use, it's a really cool feature that new users should know exist and "sneaking it in" as the first option by default seems to be a good way of "informing" the new user. Having said that, I'm sure that those who want *their* method as the first option become annoyed when it isn't (just as I get annoyed at the multitude of windows that keep popping up when I expect tabs in 1.1). To comment #17 - I have 4 Linux boxes at home and none have a middle mouse button. The majority of the time I use a laptop which has an eraser head mouse and two buttons. Buying a $20 isn't acceptable because it's one more thing to lug around. And finally, I fail to see how either ordering "breaks" mozilla. Finally, I hope that a pref option does come about. But in case it doesn't point me to the file where the order is specified so I can put "open in tab" first ;-)
How to fix it... The versions of Mozilla with the Tab/Window order fixed should also create new profiles with a preference set to 1 (the name of this preference I leave to your imagination). When the fixed version reads profiles created from the older versions of Mozilla 1.0, this preference would be read as 0 as it doesn't exist. When set to 0 this preference would put Tab first in the menu order. When set to 1 it would put Window first in the menu order. Old users would be happy as they notice no difference, new users would have the fixed order. Anyone who's that bothered can mess around with prefs.js/user.js and set it up the way they want.
I wholeheartedly agree with Matthew Miller's comment #1. There are users who use both tabs and windows; this is one of the reasons why we have both. And if you use both, it _makes a lot of sense_ to have different actions as middle-click and as the first item in the context menu. That way, both actions can be completed very quickly without wasting time moving the mouse around. Personally, I think New Tab should be first (for New Window, there's always middle-click, or ctrl-click if you don't have a wheel mouse). But enough people disagree vehemently with me that I think this should be configurable. So can we agree to what Jason proposes in comment #18 and make it configurable? Something like [ ] Show New Tab / Open Tab first ( ) in menus People, what do you think?
*** Bug 151804 has been marked as a duplicate of this bug. ***
Simplified and clarified: [ ] Show New Tab in menus ( ) before New Window.
I think Marlon's view is something like (and if it isn't, then call it my view) file>new> (app specific) Browser Tab - (suite global) Navigator Window And that's fine by me. it solves a stupid consistency issue w/ Navigator window jumping from the suite section into the app section. However, that doesn't solve the context menu. My hope is that people would be willing to only get two items [open] and [open in <window/tab>] {depending on preference}. To use the alternative type, the user would be expected to create a container and drag the link into it. The number of additional GUI Prefs this comment encourages is precisely ZERO. note that the strings "[ ] foo ( ) bar." and "( ) no Second Option." are not valid mozilla ascii pref art. the following strings are: "fish color: ( ) red (*) blue" "burger toppings: [x] lettuce [x] tomato" "sandwich. ( ) hamburger (*) veggieburger with [x] cheese"
Timeless -- if your hope comes true, *I* hope [open] isn't above [open in new whatever]. That would be truly unfortunte, since it's just duplicating the left-click functionality.
fair enough.
timeless, your suggestion of an 'open' item which would do the same as left-clicking is covered by bug 64749.
> not valid mozilla ascii pref art Revisiting pref representation: [ ] Show New Tab in menus [ ] before New Window Is that correct? (I'm assuming the objection was to the characters used and not the fact that it was only on one line?) How do you visually represent the fact that the 2nd check box is greyed out (non-selectable) if the first one is not checked?
I want tabs on top in the right click menu, or an option in the tabbed browsing preferences box. Isn't tab browsing a major part of mozilla (its one of the biggest reasons I switched from IE)? and 90% of the world uses a two button mouse, so i don't know what your talking about with this middle button, you mean my scroll thing? on my Wheel Mouse Optical (M$) the default action is to open a new window with mozilla.
> on my Wheel Mouse Optical (M$) the default action is to open a new window with > mozilla. You'd best check the box at Edit > Preferences > Navigator > Tabbed Browsing > Open tabs instead of windows for > Middle-click or control-click of links in a Web page then. :-)
Thank you alex for the tip. I just checked the help file, why is this not in there?
My personal view - and this is a very personal one indeed - is that the "Open in New Tab" should not even be visible when tabbed browsing is not enabled. My reasons are: 1) The browser defaults to what every other browser is like. No tabs, and the menu shows "Open in New Window". 2) If the user enables tabbed browsing, the code simply sets the visible property to true. No more switching positions. 3) Consistency. A user can be in "tabs and windows mode" or he can be in "windows-only mode". You should also add to this the bug that causes target="_blank open" in a new tab when in tabbed mode. This also means less prefs, in fact just a single pref: Enable Tabbed Browsing. If my views are not consistent with this bug, it may be better if I file this as a separate bug where I can expound on it more.
> "Open in New Tab" should not even be visible when tabbed > browsing is not enabled. See bug 124973, which may be what you want.
Hiding tabbed browsing when it's disabled in the prefs doesn't help here. If it's disabled by default in the prefs mozilla behaves just like another browser, so we lose a major feature that gets us major bonus points in the press reviews, and from new users. And if it's enabled by default we're back at the original discussion of what to put at the top: "new window" or "new tab"?
<off topic> > we lose a major feature Please take discussion of bug 124973 elsewhere. </off topic> > we're back at the original discussion of what to put at the top: > "new window" or "new tab"? Which is what this bug is trying to figure out, based on a preference rather than hardcoding a solution.
Jason: Hmm, that bug does have some of the things I want. But that bug is for people who don't like tabs. I love tabs and I just want greater organization. Furthermore, what I am thinking of has a wider scope than just the ability to disable tabs. Filed Bug 161466.
Blocks: 161466
In the last couple of days there has been a lot of discussion in mozillazine about this. (Somewhat misplaced under topic "Mozilla Branches for 1.1", but once I saw it started, I couldn't resist chiming in). Alex pointed out to me that I had suggested exactly the solution proposed by Jason when creating this bug. I am happy with that proposal or, if a new pref isn't as big a deal as I think it is, an entirely separate preference for the order shown in the right click menu. We do need to make it adjustable for Mozilla Users who are still in the land of 2-button mice. File Menu consistency doesn't look like a big deal for me, because the right click menu has a context (what URL is to be opened), and the File Menu item doesn't (it needs to be filled via bookmark, or pasted text, or typing, after being created). But I'll take tab-on-top in the right-click menu ANY WAY I CAN GET IT. Thanks, and I'm voting for this bug.
I think this should be WONTFIX. We have too many prefs, so it shouldn't be a pref, and I think it would get very confusing if we changed the order of menu items based on the current prefs.
I do not see any reason to be concerned about "confusion." The menus will be consistant based on the user's preference; most people will set this pref once and never change it again. If the user creates a new profile or uses someone else's computer then I suppose that there is a possibility that they might accidently choose "New Tab" instead of "New Window" but I doubt that the user will be "confused" by that happenning. This much desired change in menu order is certainly will not cause any more confusion than is caused by the ability to have the side bar, personal tool bar, status bar, component bar, and navigation tool bar all disabled; or being able to customize the navigation bar by excluding or including various buttons; or having the user pref for email to default to plain text without having an inuitive means of dynamically switching to HTML enhanced format. I see no justification for marking this as WONTFIX.
Simply saying "we have too many prefs" is a bad reason for rejecting the addition of any more. While it may, in general terms, caution against adding more, if there is sufficient reason for another then it should be added. (Also, the fact that there are "too many" can be alternately solved by cleaning up existing ones, both at the backend and in the UI presentation.)
We have no other prefs for deciding the order of menu items. If we add a pref for deciding the order of Open In New Window/Tab, should we also add a pref for, say, moving "Bookmark This Link" below "Save Link Target As" and "Copy Link Location" on the link context menu? If yes, then where should we stop? If no, then what makes this an exception? This should definitely be WONTFIX.
The difference is that in *this* case, whether Tabs or Windows is listed first is a huge hot topic. Opinion is divided almost 50/50 on what order the should appear. So far I've seen no such discussion with regard to the order of other context menu items. All you have to do is look at the Newsgroups to see how many people want the current order reverse. (And if it were, just as many people would want it reversed again, and so on.) The only way to "resolve" the dispute (because if this bug is closed, another will be opened, and so on...) is to have the order of these particular items determined by user preference in some fashion rather than by hardcoding it.
The module owner has decided that "We're not going to add a pref to list Open Link in New Tab before Open Link in New Window" (bug 161466 comment 26). Marking WONTFIX.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Jag is the module owner of UI design? I had thought that MPT was the module owner here. This is not a tabbed browsing issue specifically. I will not reopen this bug, but I would like some explicit clarification. (I feel that you may have marked it WONTFIX out of personal preference rather than for procedural reasons - even if Jag really is the module owner, it should be up to him to mark it WONTFIX, not you.)
Jag is the owner of tabbed browsing. If this is not a tabbed browsing issue specifically, what is it?
This is a UI design issue. We are not trying to introduce new tabbed browsing functionality - we are discussing how the UI should appear. Look at the Component under which this bug is listed, and look at who it has been Assigned to.
Changing component to Tabbed Browser. User Interface Design component is being removed; see bug 167289.
Component: User Interface Design → Tabbed Browser
No UI design module => jag is definitely module owner here. VERIFIED WONTFIX per module owner.
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.