Bug 123241 - Please move "Close Other Tabs" back to main tab drop-down.
Summary: Please move "Close Other Tabs" back to main tab drop-down.
Status: RESOLVED WORKSFORME
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: FreeBSD Ports Linux
: NOR normal
Target Milestone: ---
Assignee: Thomas Zander
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-07 19:00 UTC by Clark C. Evans
Modified: 2008-05-04 23:18 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Patch for KDE-3.4 BRANCH (3.68 KB, patch)
2006-03-09 04:10 UTC, James Richard Tyrer
Details
Image of Tab menu after applying the patch. (15.10 KB, image/png)
2006-03-09 07:05 UTC, James Richard Tyrer
Details
Patch for KDE-3.4 BRANCH (4.73 KB, patch)
2006-03-12 07:01 UTC, James Richard Tyrer
Details
Image of Tab menu after applying the patch. (12.50 KB, image/png)
2006-03-12 07:07 UTC, James Richard Tyrer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Clark C. Evans 2006-03-07 19:00:46 UTC
Version:            (using KDE KDE 3.5.1)
Installed from:    FreeBSD Ports

This is a rather severe user-interface bug (not a feature request).

A few releases ago, the option "Close Other Tabs" was moved from the general tab-drop down list into the "Other-Tabs" sub-list.  This effectively makes this very valueable feature... useless.  This is a user interface *bug*.  Please put "Close Other Tabs" back in the regular tab drop-down where it can be used.

   Current Work-Around:  Open the tab you want
   to keep in a "new window", then close 
   the existing window, tab over to the new
   window, and resize-it as needed.  *ouch*

This bug has effectively made me switch to Firefox for general web-browsing (even though Konqueror is much faster and better).  I often open up N tabs when browsing a few sites; and I need a way to close them all in one action.  Having to access this common operation in a sub-list makes it unusable.   It is far easier to do the workaround above then bother with using the sub-list-dropdown.  Alternatively, can this be a hot-key?

This bug is similar to #85097 but far more specific; and I think they are separable issues.
Comment 1 Thomas Zander 2006-03-07 22:30:41 UTC
If you spent time to open a load of tabs your arguing that it should be a single action to close it seems a bit odd to me. Just take a little more time to close each tab.
Next to that blindly asserting that an entry in a submenu suddenly is 'useless' seems to have absolutely no backing by theory whatsoever.  If thats the best argument you can come up with, then please accept that I close this bug as INVALID.
If you disagree, please search through usability mailinglist archives, I do think the decision about moving this can be found there so you don't have to repeat already made arguments.

As to your request to add a shortcut; you can do that in the Settings->Configure Shortcuts dialog.

Cheers!
Comment 2 Clark C. Evans 2006-03-08 00:32:15 UTC
I'm re-opening this bug.  Please accept my argument to your response:

| If you spent time to open a load of tabs your arguing that it 
| should be a single action to close it seems a bit odd to me. Just
| take a little more time to close each tab.

Why even have "Close Other Tabs" then?  Just remove it from the menu!

The option exists because it is valueable -- other browsers (Firefox,
Opera, and soon the new version of IE) have it because it is valuable 
and you're suggestion is not helpful.  This feature *was* valueable 
in earlier versions of Konqueror; it is no longer.

| Next to that blindly asserting that an entry in a submenu suddenly is
| 'useless' seems to have absolutely no backing by theory whatsoever. 

1. The "workaround" I posted takes _less_ time than the actual feature;
that is, I can open the current window in a new browser, close the
current browser, and alt-tab over to the new browser window in *less*
time than it takes to invoke this feature.

2. You're placement of this feature requires use of a mouse *while*
holding down a key.  This is painful for anyone with even moderate
wrist fatigue; it requires mental consentration since the option
is at the *bottom* of a variable-length list of windows.  Opportunity
for error are very high.  

Is there even *one* reason why this makes sense?

| If you disagree, please search through usability mailinglist archives,

I did before I posted.  The arguments are:

  1. It is related to "other tabs" hence it belongs in a sub-menu 
     (a non-sequitur, IMHO)

  2. It belongs at the bottom of this sub-menu since it is 
     a "close" operation (for hobgoblinish consistency)

Neither of these arguments are even remotely compelling; the
feature was *fine* before someone tried to "fix" it.  If you
think I'm missing something, please give me the *exact* emails
you're referring to.

| I do think the decision about moving this can be found there 
| so you don't have to repeat already made arguments.

I don't think an actual "user" of this feature was represented
in those arguments; or I would have seen my problems presented
and addressed.  They have not.

| As to your request to add a shortcut; you can do that in the
| Settings->Configure Shortcuts dialog.

Yes; I'm aware of that.  This feature should be useable from
a user who uses a mouse -- and it isn't.
Comment 3 James Richard Tyrer 2006-03-08 03:03:31 UTC
I agree that the current tab menu needs work.

I also point out that the: "Other Tabs" item should be at the end of the list since it opens a submenu which sometimes covers the primary menu.
Comment 4 Aaron J. Seigo 2006-03-08 03:16:08 UTC
please don't reopen bugs that the owner (or developer taking responsibility for it) has closed. you can, of course, continue to comment on it and those comments will be emailed to the owner email and archived on the BR#.

for the record, i agree with thomas (who happens to specialize in usability, btw =)

> You're placement of this feature requires use of a mouse *while* 
> holding down a key.

actually, you can just right click (and release) and then navigate the menu freely. i use this myself in menus all the time.
Comment 5 jos poortvliet 2006-03-08 11:37:23 UTC
sorry, but i want to add my comments here: i was looking for this feature a few days ago, and found the location in 'other tabs' very logical and convenient. 

putting such a (rarely used) feature in the toplevel menu is cluttering.

and don't say the 'feature isn't available', as it is - and its in a logical place. using the submenu got easier and more efficient thanx to the patch, so i'd say keep the option in the submenu.
Comment 6 Clark C. Evans 2006-03-08 19:38:02 UTC
I'm re-opening this bug again.  If it is closed, then people who search
(using the default settings) for "close other tabs" in the bug-search
screen won't find this bug and hence won't comment.  The KDE development
group should at least give this bug 9-12 months for others to find and
share their opinion on the topic.   I will continue to re-open this 
bug unless/untill I'm given adequate *professional* response; or a
year passes and I'm proven wrong (already I have one person who confirmed
the existence of this usability bug -- I expect more to chime in over
time).

| ------ Additional Comment #3 From James Richard Tyrer 2006-03-08 03:03
| I agree that the current tab menu needs work. I also point out that
| the: "Other Tabs" item should be at the end of the list since it
| opens a submenu which sometimes covers the primary menu.

Thank you.

| ------- Additional Comment #4 From Aaron J. Seigo 2006-03-08 03:16
| please don't reopen bugs that the owner (or developer taking
| responsibility for it) has closed

The option is there and it explicitly says that I can re-open it
if I am the reporter.  See above for my objection to having this
bug closed *before* it has been discussed.  So far the development
team has not provided *any* resonable justification for their
arbitrary decision.  Justfication that is needed, IMHO, since
your browser behaves in ways very different from other browsers.

| for the record, i agree with thomas (who happens to specialize in
| usability, btw =)

Do you have any particular reason for your agreement?  If Thomas has an
advanced degree in usability; I'd like to know under what theories he is
asserting his decision.  It's not like other people (such as myself)
aren't allowed to have a "usability nose".

For your information, in my applications I *log* feature use in my
custom applications so that I know:

  (a) what features I *thought* would be useful, but arn't
      being used - then I can ask the users what's wrong

  (b) what features are being used frequently, so that I can look
      to make them more convient

  (c) improve training on unused features, or simply remove them

What is your methodology, besides asserting that you're an expert and
that (by contrast) other people arn't?  Your unwillingness to listen
to an *actual* user here is just mind boggling.

If you're group wants to get actual data upon which to make *objective*
decisions, then I suggest a counter mechanism that logs:

  (a) how often a person uses konqueror,
  (b) records the frequency of menu selections,
  (c) summarizes the results at the end of a
      3-month period and posts them to a database,
  (d) produce actual tabulations of usability by
      feature/experince for these kinds of choices.

| ------- Additional Comment #5 From jos poortvliet 2006-03-08 11:37
| putting such a (rarely used) feature

This doesn't follow my experience; I use "close other tabs" at least
2-5x more than any other option in this menu.  What other options
have you used?

| feature in the toplevel menu is cluttering

It isn't cluttering; this menu has 6 items in it, no reason why it
couldn't have double that amount /w a few dividers (most other menus
in Konqueror have about a dozen items; divided into 3 groups of 4);
by your definition alot of the menus in Konqueror must be "cluttered",
including the right-click pop-up menu.

| and don't say the 'feature isn't available', as it is - and its in a
| logical place. using the submenu got easier and more efficient thanx to
| the patch, so i'd say keep the option in the submenu.

If it isn't easy to use, for all practical purposes, it is
unusable.

Clark
Comment 7 Clark C. Evans 2006-03-08 19:48:15 UTC
I'd like to note that one person seems to think that a "close other
tabs" is important enough that it deserves not only an entry in the 
context menu for a tab; but he would not mind having it as a 
*toolbar button*.  Admittedly this is for a different product, 
however, it demonstrates the value of this feature and that it
shouldn't be buried at the bottom of a sub-menu.

http://bugs.kde.org/show_bug.cgi?id=122170

Clark
Comment 8 James Richard Tyrer 2006-03-09 04:10:51 UTC
Created attachment 15020 [details]
Patch for KDE-3.4 BRANCH

Fixing this problem is not difficult.

I suppose that it should be run by the HCI people before it can be committed.
Comment 9 Clark C. Evans 2006-03-09 06:03:53 UTC
James,

Thank you for taking time to create a patch!  A separate (but
related) bug, http://bugs.kde.org/show_bug.cgi?id=85097, suggests
that the list of "Other Tabs" be dropped entirely.  Your patch
gave me an idea: could this list be moved to a push-button 
drop-down on the main tab-bar?  This is where I go if I want to
switch-tabs; perhaps if the list were there it might get used.

Kind Regards,

Clark
Comment 10 James Richard Tyrer 2006-03-09 07:03:32 UTC
Re: comment #9

I think that having "Other Tabs" on the menu is probably the best solution, but it should be at the bottom of the list so the submenu doesn't get in the way. 

I don't see it being used much but other users might use it a lot.  Perhaps we need to consider it it would be better in the "Window" menu, or just eliminated.  Perhaps someone has some actual data on how much it is used.
Comment 11 James Richard Tyrer 2006-03-09 07:05:57 UTC
Created attachment 15021 [details]
Image of Tab menu after applying the patch.
Comment 12 Gilles Schintgen 2006-03-09 16:10:55 UTC
Hi,
I'd also like to plead in favour of a readily available "Close Other Tabs" feature. One of my main (if not *the* main) usage patterns in any decent browser is the following:
* do a google search
* open half a dozen new tabs
* in each tab open the most promising links in new tabs
* inspect the 15-25 tabs
* as soon as the most relevant page is determined, close other tabs
It's important to note that I'd *never* close each tab individually since that would take two additional clicks *per tab*. If you have a closer look at the procedure above you'll also notice that "Close Other Tabs" is in fact the *only* tab menu entry that is ever used!
Hence, in my very personal view, "Close Other Tabs" is by far the most important feature of tabbed browsing.
Comment 13 James Richard Tyrer 2006-03-10 03:53:25 UTC
This is now being discussed on: <kde-usability@kde.org>

I should probably mention what I would do.

I would eliminate: "Reload Tab" since it is redundant -- you can do it easier with either the ToolBar or by using the context menu for the document currently displayed.

I would have only these 4 items:

New Tab
Duplicate Tab
Detach Tab
Close Tab

in the tab context menu.

I would move the other three:

Reload All Tabs
Close Other Tabs <-- probably would need a slightly different string.
Other Tabs <-- would also need a name change.

to the "Window" item in the main MenuBar (with 'Other' changed to 'Inactive' or something like that).  If this is too many items, we can have all tab related items in a "Tabs" submenu.

If there is any support for this, I can make a patch for that as well.

I also note that I would like to have: "Move Tab Left/Right" available without having to use the main MenuBar (I don't like shortcut keys).  I would at these to the top of the context menu.
Comment 14 Gilles Schintgen 2006-03-10 17:42:20 UTC
> I should probably mention what I would do.

Thanks a lot!

> I would eliminate: "Reload Tab" since it is redundant -- you can do it 
> easier with either the ToolBar or by using the context menu for the
> document currently displayed.

Agreed.

> I would have only these 4 items:
>
> New Tab
> Duplicate Tab
> Detach Tab
> Close Tab

Hmm, I'm missing something ;-)

> I would move the other three:
>
> Reload All Tabs
> Close Other Tabs <-- probably would need a slightly different string.
> Other Tabs <-- would also need a name change.
>
> to the "Window" item in the main MenuBar (with 'Other' changed to
> 'Inactive' or something like that).  If this is too many items, we can have
> all tab related items in a "Tabs" submenu.

I'd prefer to have Close Other Tabs in the tab context menu. But *please* 
don't hide it in a submenu of the main toolbar. That would definitely kill 
this feature. The more accessible it is, the better!

The whole point of this bug report is that Close Other Tabs is hidden in a 
submenu. Now at least it's in a sensible location, namely the tab context 
menu. IMO it would make it even worse to move it to the main menu bar. While 
browsing the www, I normally don't need any of the functions in the main menu 
bar (except printing, archive web page, save as, bookmark management).
As I've already explained, Close Other Tabs is one of the most used functions 
in a browser (at least in a certain usage pattern). Moving it to a location 
where normally only the less used functionality can be found would be a 
mistake.

My personal favourite would be the following:

New Tab
Duplicate Tab
-----
Close Other Tabs
-----
Detach Tab
Close Tab

> I also note that I would like to have: "Move Tab Left/Right" available
> without having to use the main MenuBar (I don't like shortcut keys).  I
> would at these to the top of the context menu.

I can only say that, from my very personal point of view, I'd consider these 
actions to be "bloat". Obviously, this is simply a consequence of differing 
usage patterns...
BTW, how difficult would it be to move tabs by drag'n'drop? That would be the 
most intuitive way to move them around.

Thanks for reading this rather lengthy comment.

Gilles
Comment 15 Clark C. Evans 2006-03-10 17:55:51 UTC
I really don't care what the solution is, as long as "Close Other Tabs" is
easily accessable; ideally by right-clicking on the tab you want to keep.
Gilles' suggestion is fine with me; but please don't move Close Other Tabs
into a sub-menu of the Go top menu.  The whole point of this thread is that
"Close Other Tabs" is very valueable and I would prefer it not be buried in
a sub-menu.   Thank you Kindly,  Clark 
Comment 16 James Richard Tyrer 2006-03-10 18:37:39 UTC
To clarify, I'm suggesting that the context menu for a tab should only contain actions for that tab:

Move Tab Left
Move Tab Right
--------------
New Tab 
Duplicate Tab 
Detach Tab 
Close Tab

This would be an improvement from the 'clutter' issue standpoint, but it would raise other issues.  This leaves the question of where the other two functions and the "Other Tabs" submenu should be accessed.

Also, consider that: "Close Other & "Reload All Tabs" can be added to a toolbar if you use them a lot.  Perhaps we need a "tabs toolbar" so that they can be added and hidden as a group.

One small issue with this is that "Close Other Tabs" currently does not have its own icon.  It currently uses: "tab_remove" which is the same icon as: "Close Tab".

Perhaps an 'other tabs' context menu would be better, but where should a user right click to open it?  Currently, if you right click the empty space in the tab bar you get the tab context menu.  It could be the 'other tabs' context menu, but there isn't always empty space.

Currently, Drag 'n' Drop will only copy (duplicate) tabs.  Yes, I would like it if I could also move tabs with Drag 'n' Drop.
Comment 17 Clark C. Evans 2006-03-10 18:53:15 UTC
I've never used Duplicate Tab; and I only use Detach Tab currently
since Close Other Tabs isn't available (I use Detach Tab to save
the tab I want, then I ALT-TAB back to the previous window, use 
ALT-F4 to close, and then ALT-TAB back).   Note that Firefox has
neither "Duplicate" nor "Detach" tab.  I don't care about moving
tabs around, this is just "more clutter" for me.  So, IMHO, if 
you're going to remove clutter -- let's start with the basics:

   New Tab
   Keep Tab (Close Others)
   Close Tab

Everything else is clutter!  As I posted to the kde-usability list, 
perhaps if you rename "Close Other Tabs", to "Keep Tab (Close Others)"
you will better see it's value and that it has very little to do with 
"Other Tabs".

Please, please, keep "Close Other Tabs" in that context menu!

Best,

Clark
Comment 18 Clark C. Evans 2006-03-10 18:56:21 UTC
The corresponding discussion on KDE-USABILITY is at:
http://lists.kde.org/?l=kde-usability&m=114187476107053&w=2
Comment 19 Thomas Zander 2006-03-12 02:35:57 UTC
> | for the record, i agree with thomas (who happens to specialize in
> | usability, btw =)
>
>  Do you have any particular reason for your agreement?  If Thomas has
> an advanced degree in usability; I'd like to know under what theories
> he is asserting his decision.  It's not like other people (such as
> myself) aren't allowed to have a "usability nose".

Your request to make me explain what has been openly discussed and agree upon by the usability ML earlier is incorrect.  Its silly to ask anyone to explain again and again why a certain decision was made everytime someone else disagrees.  It does not allow any more time to actually do anything usefull, just do talk about previously made decisions.

There is an obvious exception to this rule, that is if someone has a good reasoning saying the current solution is wrong. In contrast, the reasoning I have read in this bugreport misses a base in theory and often contradicts itself.  Now; I closed this bug for a reason since, well, its not a bug.

I'll leave the report open for now since you say its hard to find closed bugs in this system.  But before anything is actually changed be sure to get an OK from the HCI group.

Some quick pointers as to why we made this change last year, which I may add are also in the mailing list archives, but anyway.
1) Quit or Close always go at the bottom of a menu, which is what we have now.
2) Having two close buttons next to each other that work on different context means that as soon as the user want to use one he has to read and understand both concepts before he can make an educated choice.  This means the interface just got a whole lot harder to use.
3) having 2 items next to each other that both are destructive is bad usability since a mistake is quite problematic.   We found in user tests that users made this mistake quite often and were left with the wrong tab(s) being closed.

Separating out the different contexts (this tab or all the other tabs) into a submenu satisfies all above issues.

I hope that clears up any misconceptions about this menu.
Comment 20 James Richard Tyrer 2006-03-12 07:01:55 UTC
Created attachment 15069 [details]
Patch for KDE-3.4 BRANCH

It appears that the only thing which has general agreement is to remove the
"Reload" item.	So, I have changed the patch.
Comment 21 James Richard Tyrer 2006-03-12 07:07:13 UTC
Created attachment 15070 [details]
Image of Tab menu after applying the patch.
Comment 22 Germain Garand 2006-03-21 11:15:50 UTC
re #19:
> 1) Quit or Close always go at the bottom of a menu, which is what we have now. 

Well, it should really be at the bottom of the *static* entries in this menu,
not at the bottom of the *dynamical* list of tabs , which doesn't make any sense, as you are precisely here not to be bothered by them individually!
Comment 23 Thomas Zander 2006-03-23 01:14:15 UTC
On Tuesday 21 March 2006 22:15, Germain Garand wrote:
> > 1) Quit or Close always go at the bottom of a menu, which is what we
> > have now.
> Well, it should really be at the bottom of the *static* entries in this
> menu, not at the bottom of the *dynamical* list of tabs , which doesn't
> make any sense, as you are precisely here not to be bothered by them
> individually!


I don't follow this argument.  Please state why you think this and the 
reasons why you believe your reasoning is going to help many more users 
that use this interface as well.

I personally am completely convinced the user will not grasp the 
difference between so called static and dynamic entries in a popup menu 
(which by its very nature is dynamic)
Comment 24 Adrian Dziubek 2006-05-09 22:21:19 UTC
Some random quotes:
>This doesn't follow my experience; I use "close other tabs" at least 
>2-5x more than any other option in this menu.  What other options 
>have you used?
I agree, I use this feature most often of the whole menu. The usability pattern was given (see comment #12), I do it exactly the same way. Now I moved to keyboard, but I'm missing the feature (as previously noted, it is not _the_ feature anymore, being moved to submenu).

I occasionally use new tab, deatach and duplicate, but I can imagine other patterns, so I'm just here to say: I want "Close Other Tabs" back! I don't need a complete redesign. I could only say that the list in "Other Tabs" seems completely unusable, since You see the tabs anyway.

> 3) having 2 items next to each other that both are destructive is bad
> usability since a mistake is quite problematic.   We found in user tests that
> users made this mistake quite often and were left with the wrong tab(s) being
> closed. 
I personally did the error sometimes, but I still miss the feature anyway. Removing the close tab and leaving only the [X] in the right corner would be less painful for me, but by no means I recommend this (there are for sure people using "Close Tab" as well).
 
> Separating out the different contexts (this tab or all the other tabs) into a
> submenu satisfies all above issues. 
It doesn't, it kills the close other tabs feature. Separation line solves this problem and this was the previous solution here.

And the very fact, that nobody complained about mistaking the "Close Tab" and "Close Other Tabs" is a good argument for this.
Comment 25 Adrian Dziubek 2006-05-11 17:49:43 UTC
I don't know if I already don't cross some magical politeness border with it and I want to say that I really appreciate the work Konqueror team has been doing, but I can't keep myself from posting this article. Somewhere in the middle of this article Linus is saying, what I would say, if I were so fluent with expressing myself. It immediately reminded me the case here:

http://lists.osdl.org/pipermail/desktop_architects/2005-December/000486.html

Sorry for spaming anyway.
Comment 26 Jaime Torres 2008-05-02 22:02:12 UTC
I am not discussing if the "close other tabs" should or should not be in the main tabs menu, I'm not very good GUI person. But I must say that it should have a shortkey assigned to it (Ctrl+Alt+Shift+W is the logical one).

I must say that in kde4 trunk 20080430, in the other tabs there is a list of currently open tabs (not only other tabs), and I think it is a usability issue, because it is shown more than asked, or it is asked in the submenu other things.

Also, I would like to have the entry "close other tabs" in the window menu, just bellow the "close actual tab".
Comment 27 David Faure 2008-05-04 16:30:19 UTC
Anyone who really wants a QUICK way of closing all other tabs, should just assign a shortcut to that action -- this is what the shortcuts editor is for.

Sorry if you've discovered that you're part of a minority - it sucks, but it happens. Good that KDE is so configurable that you can actually assign a shortcut to any action -- which beats any mouse-based solution in terms of speed, so this should fit into your requirement of it being fast.
Comment 28 James Richard Tyrer 2008-05-04 17:01:51 UTC
This bug has not been resolved.  I can see that it it might be changed to a wishlist item.  But it does not work for DF and his suggestion does not resolve the issue.

Nobody has discussed my suggested path.

OTOH, if this is a usability issue, then it remains a bug.

Comment #22 appears to be correct.

It is unfortunate to find that the developers are the majority and the users are the minority, but it appears that that is the way it is with KDE.  Closing bugs for political reasons accomplishes nothing.  

This issue can only be properly resolved by a usability study.  TZ suggests that the usability issue has already been addressed.  I believe that the current configuration still has usability issues.
Comment 29 Thomas Zander 2008-05-04 17:30:43 UTC
> This issue can only be properly resolved by a usability study.
> TZ suggests that the usability issue has already been addressed. 
> I believe that the current configuration still has usability issues. 

Usability does not mean its perfect for every user, we have configurability for that, usability means its the best it can be for our target group of users.
So David said it entirely correct; you may realize you are the minority and thus its less then perfect for you. Please use the configuration options we provide to make it better for you.
Comment 30 David Faure 2008-05-04 21:44:37 UTC
> developers are the majority and the users are the minority

This is definitely NOT what I said, and you know it.
The majority of users do not use "Close Other Tabs", that's a fact that should be obvious IMHO.
Otherwise this issue would have a huge number of votes and would pop up at trade shows, etc.
But it does not. So the users who use this feature are a minority. No problem though, they can
easily configure a shortcut and be happy too.
Comment 31 James Richard Tyrer 2008-05-04 23:18:37 UTC
Re Comment #30

Why a "Straw Man"?  The issue is the menu.  I must say that this bug along with Bug 85097 have degenerated into wider criticism of the tab's context menu than the original reporter's statements.  However, the issues are related.

My suggestion is to remove the "Other Tabs" sub menu and replace it with "Close Other Tabs".  This would seem to resolve both issues.

> The majority of users do not use <whatever_feature>

This is often true, but I don't think that we want to remove every such feature.  It could also be said that 'The majority of users don't use the "Other Tabs" sub menu except to use "Close Other Tabs' -- I have no idea if it is true or not.

IAC, since this bug has been closed without resolving the issues, I will switch to bug 85097.