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.