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.