Closed Bug 191492 Opened 22 years ago Closed 15 years ago

Modifier+"Close Tab" should close other tabs

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

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

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: torben, Unassigned)

Details

"Close other tabs" as an item in the tab context menu had unacceptable
consequences (103354), yet it was a feature I, and probably others, used several
times a day. A practically fool-proof way of doing this would be to change
"Close tab" to "Close other tabs" when a modifer key (option on mac, shift on
win & *nix(?)) is pressed. The changing of a menu item when option is pressed is
quite common on mac.
I agree that there needs to be some method of easily closing all other tabs, and
I mean natively, not with an add-on.  I frequently used to do this and am now
pretty much stuck (well, not stuck but annoyed).
Actually, if you ask me, Reload All Tabs should also go the way of Close All
Tabs.   (Otherwise it's inconsistent.) If a modifier is introduced then using it
could effect every menu item that normally only applies to a single tab.
What about a pref for this in tabbed browing options ?
What about having all these advanced options appear in the context menu only
when a modifier key is pressed ?
Re comment 3: I do not want any stupid prefs, nor any anoying popup alerts (with
or without a "do not ask again" check box), I just want a simple way of closing
all other tabs: right-click on a tab and the menu says "Close tab", press the
modifier key and it changes to "Close other tabs". The same thing should
probably happen with "Reload (all) tab(s)" as suggested in comment 2.

Re comment 4: yes, that is what I mean.
Just want to help, and if I am thanked this way...
Another consideration would be to add a dropmarker to the "Close Tab" button,
much like is done with "Back", Forward" and "Print". Actually, that method would
be more consistent than some unknowable "modifier key" alone AND the fact that
the dropmarker is part of the "Close Tab" button makes it very unlikely that
folks will accidentally select it...
> some unknowable "modifier key" alone

It could be easily documented in the context menu, which could read, for example:

Close Tab (Ctrl=All)
Re: comment #5 : what would be wrong with a pref that you would be able to set
ONCE, to give your preferred bahavior? Basically the pref would be a boolean:

enable "close other tabs" ?

If you wanted the thing, you set it yes once and forget about it. 

Im not opposed to a modifier, or some other way of making the function
available. Just so that people that DONT want it, cant accidentally select it.
Close tabs and close all tabs is risky. Not the first time I've closed a tab
accidently, but nevertheless I miss it.

Its mainly risky because we dont have a way back. What about adding an Undo
Close Tab, or maybe re-use Edit->Undo for it? Or the history back button somehow?

I dont think that a modifier key is a good idea, because allmost no one will
know about it. (is there any menu that uses modifier keys? If yes, I missed it.)

What about a sub menu? Could be All Tabs->Close and All Tabs->Reload for now.
(mmmh, what about All Tabs->Bookmark?) 
Its very unlikely that a sub menu is hit accidently.

For all the pref fans: What about a hidden pref to enable a visible pref to
re-enable close all? ;D
I personally never used "close others tabs", as I always close tabs as soon as
I've read them, but how about placing this option in the contextmanu on a
right-click on the "close" button on the tabbar? (Where it already existed in
older builds.)
A modifier key seems to be to me somewhat undesirable, as when (for example)
that key happens to be stuck just as you were trying to close on single tab,
you'd lose everything you didn't want to close. However, people don't as a rule
right-click the close button, and yet it'd still make some sort of sense for an
option dealing with closing tabs to be located there. (Both proposals seem to me
to be equally undiscoverable for novice users, so that shouldn't be held against
this one.)
Only providing the option there would mean that the option to "close other tabs"
for a non-current tab would still be lost, but as I understand the browsing
behaviour of most people missing this option, everyone always seems to be only
wanting to keep the current tab, right?

It'd prevent adding yet another pref, which can only be considered to be a good
thing, it wouldn't endanger any regular users, and yet it would still maintain
most of the functionality for power users who want it.
If there were preferences, you'd hassle with this pref ONCE, and then it's gone.
I am sure that won't kill anyone. A drop-marker sounds like the most reasonable
solution, though. The whole problem with Close All Tabs before was that you
could select it and not mean to. I've lost tons of data because of it. With a
drop-marker, you have to go out of your way (at least from the context of the
tab) in order to select it. Yet, it's still there for the power users. All the
rest of us ask is that CAT stops causing data loss. If it doesn't, another
ticket will be opened and the cycle starts again.

May I make a few suggestions?

1)  We will NOT have a pref for whether this menuitem appears.  Period.
2)  It makes sense to have _some_ sort of way to achieve this functionality
3)  The newsgroups are a better place to discuss various approaches to #2 than a
    bug is.  Once consensus is reached, a bug should be filed with a request for
    the approach that was agreed on.
Frederic, I am sorry if my comment 5 sounded a bit harsh, it was not meant as an
attack on you. However, as Boris points out in comment 13, a pref will probably
never be allowed (and IMHO is unecessary). (I put you back on the cc:-list so
you would see this appology, I appologize again if you find this inapropiate).

For discussion on how to best achive this, there is already a thread in
n.p.m.general ("how to get "close other tabs" back !!!").

There must be some sort of workaround, pref or modifier key, to get rid of other
tabs with small effort, otherwise tabbed browsing loses it´s best feature.
My current workaround is: 

1. copy that tab I want to hold, 
2. open a new window
3. paste the tab into it
4. select
5. press enter
6. close the old window
Is that a comfortable workaround for a missing feature?

Asking for blocking 1.3b, because this missing feature makes tabbed browsing
pretty annoying.

Yes, sometimes I lost tabs by accident, but I still prefer having "close other tabs"

Wouldn´t it be a simple solution to have "close other tabs" just open another
menue, "really close other?"
Those who clicked by accicdent simply can go back, the others simply click once
more.
Flags: blocking1.3b?
Let's get things back on track for THIS bug.  The only thing that should be
discussed here is how to implement a modifier key.  As I see it there are 2 issues:

1. Should the modifier modify only "Close Tab" or should it act as a "global"
modifier and affect all tab functions ("Reload Tab", etc.)?

2. How can we exposed this functionality in the UI?  (I already made one
suggestion in comment 8 but am not sure if I'm happy with it.)  Another
possibility might be, when the tab context menu is displayed, to alter the text
of the menu items from "Tab" to "All Tabs" when the Ctrl/Option key is pushed,
and perhaps make the font change to red or something.  Pushing the modifier key
again could toggle the items back again to their normal single "Tab" status.
Suggest W O N T F I X  because this bug would make it undiscoverable and
I've never seen context menus change with modifier keys (in windows).

Please see bug 103354 comment #85 for my suggested solution (confirmation dialog)
I have already suggested several ways of making this discoverable.  Also, the
fact that this isn't seen in Windows is a non-argument.  If you want the old
behaviour but with a confirmation dialog, then open another bug requesting that.

Please stop SPAMming this bug.
I just filed bug 191578 ("Close All Tabs" Needs a Confirmation Dialog) which is
a superior solution to getting this useful feature back. Please CC yourself and
vote there if you agree.
Re comment 16:

> 1. Should the modifier modify only "Close Tab" or should it act as a "global"
> modifier and affect all tab functions ("Reload Tab", etc.)?

A "global" behaviour would be most consistient and probably the best, I guess
there is potential for dataloss with the "Reload all tabs" function also.

> 2. How can we exposed this functionality in the UI?

I am not to happy with the suggesting in comment 8 either. The text in the
context menu should definitely change when the modifier key is pressed, the
question is whether this is enough to make this function discoverable. If this
is documented in the release note I think so.
Okay, I have an idea.

Normally:
 New Tab
 Reload Tab
 Close Tab
 ----
 Alternate Action (Ctrl)

Toggled:
 New Tab
 Reload All Tabs
 Close All Tabs
 ----
 Normal Action (Ctrl)

(Note: Also, I've created bug 191587 to deal with the alternate solution of
having an All Tabs submenu as per comment 10 here.)
Re: Comment 17
Please look back and test a little before jumping to conclusions based on
incorrect data. 
The Shift key is used in some places to allow an optional behaviour: if you
right click on a file in win98 (i've checked and they changed the behaviour in
w2k), then there's an additional menu item "Open with...", and if you select
"delete" with shift pressed, then the file bypasses the trash bin and is
permanently deleted.
Flags: blocking1.3b? → blocking1.3b-
Replace "Close other Tabs" by "Open Tab in New Window" ?

Some people are missing dearly "close other tabs", some others are glad a
dangerous source of losing tabs is closed.
I don´t see a way to get this feature back.

Wouldn´t it be better solution to replace "Close other Tabs" by "Open Tab in New
Window" ?
This will give you best of both worlds:
You get the tab you want to hold alone in a fresh new window.
You can get rid of the rest simply by deleting the old window.
There is no chance losing URLs by clicking on the wrong menu entry.

Maybe the wording "Copy Tab to New Window" is better, 
because it excludes the creation of a new empty tab in a new window.


Re comment 23:
That is bug 102132, which will not be fixed for a long time, if ever. 

All the mechanisms need for the implementation of this bug, however, should
already exist.
Re comment 24:
Bug 102132 has a lot of very restricted propositions and discussions,
so partly it´s been considered a meta bug.

Bug 102132 proposes transfer from tab to window and vice versa.
What I want is transfer from one tab to a tab in a new created window.
That gives back the functionality of "Close Other Tabs", without risking
"dataloss" for fast clickers.
Result of this action:
Old window unchanged, or less one tab.
New window with one tab, like you had clicked "close other tabs".
In the first iteration I don´t mind if this content is changed by reloading,
in the end it should be a copy.



Herman: Please discuss your idea in a different bug, it doesn't have any direct
bearing on this one.
Hermann's idea is an inadequate workaround because it would not *close* the
other tabs. The user would have to switch back to the other wndow and then close it.
FYI: See newly opened bug 191818 which calls for a File menu entry for close
other tabs.  Jag actually agrees with this one, so we may be getting the
functionality back shortly.
Note that you can't use Ctrl+Shift+W for Close Other Tabs because that's already
Close Window :-/
Since "Close other tabs" seems to be back with the fixes for bug 191818 and bug
191492 I guess this is not needed anymore. Resolving as Wontfix, if anyone still
feels this is usefull feel free to reopen.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Reopening.  I believe that this is the best and most elegant way of giving the
functionality that everybody wants while, at the same time, reducing the
possibility of dataloss.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
just my 0.2c but I miss this feature and it does make tabbed browsing a
complete pain in the ***.  One way I used it was to open links in a page
in the background while I was reading them and then switch to the tabs
when I was finished.  Now I have to just close the whole window and open
a new one when I want a similar but less satisfactory effect.

I'd vote for adding a shift modifier.  It's called "power user", just because
it's not obvious doesn't mean it's not a good paradigm.  Beginners have to
turn on tabbed browsing, they might as well learn how to use it too.  How
many beginners know about the CNTRL and ALT modifiers for moving files around ?
And the cursor actually changes in real time when you use them, on windows
that is.
I would also propose (as a possible extension to this existing bug) that the
context menus list, by default, only single-tab actions, and that the modifier
change any equivalent single-tab action to a multiple tab action - and not just
"Close Other Tabs".

I.e.

Close Tab -> Close Other Tabs
Bookmark This Tab -> Bookmark This Group of Tabs
Reload Tab -> Reload All Tabs

Holding down the modifier key would dynamically change the text listed in the
menus.  (And there should be some indication that this is available.)
I agree with Jason's suggestion in comment 33, if this is implemented the
modifier should change all single tab operations to multiple tab.
This bug makes no sense at all. Why should modifier+click ever mean
close/delete? It's too easy for unsuspecting users to hold down on a modifier
key when clicking something. If you're experimenting with keyboard shortcuts,
this is no good. If you've got a cat on your desk, no good either. There gotta
be other more elegent sol'n. This one isn't it.
I think this bug can be resolved now as WORKSFORME?
The reporter filed the bug, when 'Close Other Tabs' was removed, as some people
didn´t know how to avoid it. A lot of people, including myself, didn´t care
about sometimes closing the wrong tabs, this function has mostly been useful to us.
As there was not much chance to get a preference for this, bugs like this have
been filed, adding a complicated using Mouse&Keyboard same time scheme to get
this feature back.
I would close this bug, and reopen it the moment that pref is removed again.
Also there has been no comment or progress for more than half a year.

comment 0 starts:
"Close other tabs" as an item in the tab context menu had unacceptable
consequences (103354), yet it was a feature I, and probably others, used several
times a day. A practically fool-proof way of doing this would be 
"Close other tabs" as an item in the tab context menu had unacceptable
consequences (103354), yet it was a feature I, and probably others, used several
times a day. A practically fool-proof way of doing ...

So this bug was about getting a feature back that was removed as it was not
foolproof. It is now less foolproof than in its first implementation,
if you don´t use the annoying acknowledgement each time you want to close all
others, but everybody is glad to have it back, of those who used to use it.

The bug got resolved WONTFIX by the reporter in comment 30,
and reopened by Jason in comment 31, that has been in February.

Since "Close other tabs" seems to be back with the fixes for bug 191818 and bug
191492 I guess this is not needed anymore. Resolving as Wontfix, if anyone still
feels this is usefull feel free to reopen.

Close Other Tabs is long back, and there has been no activity in this bug,
so resolve again as the reporter wanted, feel free to reopen, if there is
something new to talk about.

Wanted to resolve, but can´t select with todays nightly:
/ (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031010
"Close other tabs" STILL has unacceptable consequences.  The fact that it's back
in the context menu doesn't change anything, so this bug is still valid -
especially since it's marked as an enhancement.

The reasoning behind me reopening it (despite the context menu item being
restored) is just as valid now as it was then.  If the module owner wants to
mark this as WONTFIX I'll be okay with that but I certainly see know reason to
mark it WORKSFORME (it doesn't).

> Why should modifier+click ever mean close/delete?

For the same reason that a regular click means to close the current tab:

Regular click = open link in current tab.  Modifier click = open link in new tab.

Regular click = close current tab.  Modifier click = close OTHER tabs.

There's nothing new or unusual about having a click mean closing/deleting
something, or a modifier changing the way that a regular click works.  Using a
modifier means it will be much more unlikely to accidentally close other tabs. 
Not *impossible*, just muchless likely.

> If you're experimenting with keyboard shortcuts, this is no good.

Reading through the bug comments would make it clear that this would not be
undocumented.  When looking at the context menu, either it would clearly state
what Ctrl click would do, or, when it Ctrl was pressed, the text would changed
from "Close tab" to "Close other tabs".  In any case, this wouldn't be something
hidden that would jump out and surprise anyone.

> If you've got a cat on your desk, no good either.

I once had a friend of mine in University who had a cat walk across her keyboard
and exit her word processing program without saving her current document.  (I
managed to retrieve it for her.)  You could say the same thing about cats w/r/t
anything...
Another parallel with the behavior of a mainstream Windows application: in
Microsoft Word, the File menu usually contains the items "Save" and "Close."
Holding down Shift when opening the File menu causes these two items to change
to "Save All" and "Close All." Pressing Shift after the menu is open does not
make them change, so there are no surprises if the cat steps on Shift after the
menu is open; clicking the item does what it says. Similarly, pressing Shift
after the context menu is open for a file does not make "Open With" appear; it
only shows up if Shift is pressed when the menu is opened. Pressing Shift while
clicking Delete does change the operation immediately, but in both cases there
is typically a confirmation dialog so the user is made aware of the difference.

What makes the most sense if this RFE were implemented would be to have the menu
normally say "Close Tab" but if Shift is pressed when the menu is opened then
change it to "Close Other Tabs."
The proper solution for this is a confirmation dialog box. That is bug 191578.

A modifier key should have no effect on the operation of a context menu. It's
too "nerdy." ;-) Suggest WONTFIX. 
Bug 191578 has absolutely nothing to do with this bug.  (A confirmation dialog
box will not close other tabs.) Both can easily be implemented at the same time,
and there'd be no similarity in terms of functionality (the only thing they have
in common is that they are both related to tabs).  This bug is not a duplicate
of that one, nor is it dependent on it.
So you want "Close Other Tabs" AND Ctrl-Shift-Alt-Z+left-click(close tab) or
whatever to do the same thing?
> So you want "Close Other Tabs" AND Ctrl-Shift-Alt-Z+left-click(close tab)
> or whatever to do the same thing?

No, go read comment #0

(Basically I want an easy way of closing all other tabs that users are less 
likely to hit by accident than what we have today - without presenting useless 
confirmation boxes)
Product: Core → SeaMonkey
Assignee: jag → nobody
Status: REOPENED → NEW
QA Contact: pmac → tabbed-browser
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Confirmation dialog came with bug 191578. Modifier keys on context menus are uncommon. WONTFIX
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.