Closed Bug 103354 Opened 23 years ago Closed 22 years ago

"close other tabs" is in a dangerous position on tab context menu

Categories

(SeaMonkey :: Tabbed Browser, defect, P1)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
mozilla1.3beta

People

(Reporter: joschi, Unassigned)

References

Details

(Keywords: dataloss, regression)

Attachments

(5 files)

patch v.1 Add box to confirm removals and reorder context menu.
2.56 KB, patch
Details | Diff | Splinter Review
v.2 get rid of other patch scraps
2.09 KB, patch
Details | Diff | Splinter Review
v.3 moved text into a .propertes for other langs. Patch can now be subjected to review.
3.76 KB, patch
Details | Diff | Splinter Review
v.4 got rid of js probs and made code nice and neat.
3.74 KB, patch
Details | Diff | Splinter Review
Remove "Close Other Tabs" menuitem.
2.76 KB, patch
bryner
: superreview+
asa
: approval+
asa
: approval1.3b+
Details | Diff | Splinter Review
The order of menu items is extremely dangerous. Having two actions with destuctively oposite effects right next to each other is not a good idea. Many times I have accidentally clicked "Close Other Tabs" when intending "Close Tab" ... I'm sure you see how annoying this could be if you are regularly keeping 8 pages open in tabs, and go to close the page you just read... boom... all those other pages are gone and you are left staring at the page you just read :) I don't have a suggestion for the order at this time, maybe this issue will vanish as more items are added to that menu, but this is a big usability issue.
Summary: tab popup menu item order is dangerous → "close other tabs" is in a dangerous position on tab context menu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: ui
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
I'm sure 'Close' and 'Close other tabs' should be swapped on the context menu consistent with windows and some gnome menus. A msgbox should also promt the user with 'All other tabs but the currently displayed tab will be removed. Are you sure you want this to happen?' to prevent mis-clicks from loosing whatever the other tabs contain by accident.
I think this menu item should be gotten rid of altogether. I don't think this is an option user's expect. The File menu doesn't have a "Close all other browser windows" menu item. I think the small benefit of increased functionality is outwayed by decreased usability due to increased UI noise.
i do not think we should get rid of it, this feature is pretty useful for tabs but i don't see (personally) the big improvement if we just switch the positions of "close tab" and "close other tabs"...
I just lost several tabs, including my bug search results, to this. Adding self to Cc.
Target Milestone: mozilla1.0 → mozilla1.0.1
the patch v4 is outdated because of changes being made to the source, isn't it? The context menu was reorganized some time ago... IMHO this bug as described in the summary is now a WONTFIX. the only interesting thing is the confirm-dialog... do you really want it? I think it would be more annoying than helpful...
There is now a separator bar between "Close Tab" (which I use constantly) and "Close Other Tabs" (which is very destructive and never what I want, ever), so that it is not *quite* so easy to hit the wrong one by mistake, but really a separator bar is thin, and it still would be fairly easy to accidentally close a dozen tabs one still wants, by mistake. I would like to be able to configure away the "Close Other Tabs" option entirely. I never use it. Don't know about the patch; I only grab the nightly builds, since I don't have the compiler needed to build Mozilla. Waiting for the day it will build under cygwin. (Is there an RFE for that someplace?)
*** Bug 107519 has been marked as a duplicate of this bug. ***
if you want to get rid of a menu, you can use your userChrome.css to display:none it.
Talking about menus: IMHO Ctrl+W command (File/Close) is even more gangerous than "Close other tabs" command. How about replacing/adding "Close window" (Ctrl+W) command with "Close Tab" command in main File menu when Tabbed Browser is activated? This way pressing Ctrl+W will close always one active tab up to last one, then the whole window is closed as normally. "Close other tabs" feels terrifying, because most people usually like to confirm visually what exactly they are closing and the tabs are closed one-by one.
> How about replacing/adding "Close window" (Ctrl+W) command > with "Close Tab" command in main File menu when Tabbed > Browser is activated? This Works For Me, Win95 OSR2, Mozilla build 2001103103 > "Close other tabs" feels terrifying, because most people > usually like to confirm visually what exactly they are > closing and the tabs are closed one-by one. Agreed, it is easy to lose data this way.
Keywords: dataloss
Reassigning to new component owner.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
QA Contact: blaker → sairuh
I agree with the request for a confirm message. To have all tabs closed without a confirm is very frustrating and it does happen all too often. Granted, you can remove it manually, but the default action should not be to wipe all tabs without a confirm.
Yes please add a confirmation window!. I regularly have between 6 and a dozen tabs open, and have accidentally closed them all at once this way.. In the meantime, I will see if I can find a way to disable it in the chrome as described earlier.. Thats not a perfect s9lution though, becuase sometimes it IS a useful function.. It just needs to have a safety..
I am in favor of either: 1) Removing "Close other tabs" from the tab context menu --or-- 2) Adding a close confirmation message upon selecting "close other tabs"
FYI: this will be in my new tabbrowser.xml update patch :) <tabbrowser.xml:snap> <method name="confirmTabClose"> <body> <![CDATA[ try { // a pref setting a preferred for this dialog if (!this.mPrefs.getBoolPref("browser.tabs.confirm-close")) return true; } catch(e) { return true; } var dialogTitle = this.mStringBundle.getString("tabs.confirmDialogTitle"); var dialogText = this.mStringBundle.getString("tabs.confirmDialogText"); var promptService = Components.classes["@mozilla.org/embedcomp/prompt-service;1"].getService(); promptService = promptService.QueryInterface(Components.interfaces.nsIPromptService); return promptService.confirm(window, dialogTitle, dialogText); ]]> </body> </method> </tabbrowser.xml:snap> This snap of code should be inserted to activate the dialog: <tabbrowser.xml:snap> if (!this.confirmTabClose()) return; </tabbrowser.xml:snap> As you see you can configure a pref to enable/disable this dialog. And please don't mess up with the tab menu.
We'll be putting a close box on each tab, making using the menu unnecessary. That then leaves a lot of room between the Close All Tabs item and the other items. Is that enough? If so I propose WONTFIXing this bug. Having an alert is not really an option; alerts should only happen when something goes wrong. (Ask mpt.)
Whiteboard: WONTFIX
Proposed fix doesn't WFM...an alert should happen when something goes wrong, AND when the user is about to do something big and destructive that can't be undone. For example, the "Are you sure you want to quit" type alert in many apps. I can see how that confirm behavior might be annoying to some, but if we're going to include hardcore features like Close All Tabs, then we need to have a way of turning it off or warning the user if they use it. The *best* solution IMHO is to group those kind of alerts in a Newbie section and allow the user to enable/disable them as a group. The user could also enable/disable hardcore features like Close All Tabs...but the prob with this bug is not the distance between the items, it's: 1) the Close All Tabs is there at all 2) you're doing a big, destructive thing with no warning to the user. At least that's how it looks from over here.
How useful is "Close other tabs"? Perhaps the solution is to just get rid of it.
I would just like to voice my agreement with jag, it just isnt useful enough to justify it potential to cause the user to loose lots of information. I routinely close 10's of tabs just clicking repeatedly on the [X] button, clicking with the middle mouse button, or using ctrl-w.
Ok, apparently this didnt make it into 1.0, even though I can't imagine I'm the only one that has lost a whole bunch of open tabs with one mis-click of the mouse. I dont know why this requires so much discussion, why it cant just be fixed in the official tree. It baffles me why a TINY fix like this didnt get included - not even so much as a pref to remove it from the menu.. Anyway, its **** me off enough now, and with 1.0 'released' I'm not waiting any more. I'm not a code hacker, and a full mozilla compile would take days on my system. So I've found a way to get this option off the menu at run-time. I publish it here for anyone else who keeps losing important work due to this ill-devised misfeature, and is also not in a position to edit the source and recompile. Maybe my doing this will prod someone who has access to the tree to put in a proper fix or preference - this is a semi-ugly hack. This works on linux, it might work on other platforms. It comes with absolutely no warranty - if you break your mozilla, or crash your system, or erase your hard drive, dont complain to me. 1. Find 'toolkit.jar'. In my RH 7.x install from the RPMs, this was in /usr/lib/mozilla-1.0.0/chrome 2. MAKE A BACKUP COPY OF THAT FILE! 3. If you didnt follow instruction #2, do it now. MAKE A BACKUP COPY! 4. Make a temporary directory somewhere, and unzip toolkit.jar into it (its really a zip file, even though it says .jar) 5. Find content/global/bindings/tabbrowser.xml in your temporary directory 6. Look for a line thats starts like this: <xul:menuitem label="&closeOtherTabs.label; This is the start of the menu item definition. In my version, it was wrapped onto 4 lines - it ends with "/>" at the end of a line 7. Delete just those lines. There is a menu seperator definition above it that you can delete too if you dont want it to look silly. 8. Re-zip all of these files up into a new toolkit.jar . Make sure it has the pathnames starting with content/... etc ... MAKE SURE YOU DONT OVERWRITE YOUR BACKUP COPY - YOU DID MAKE A BACKUP, RIGHT? 9. Name this new zip file 'toolkit.jar', and put it in place of the previous one. Restart Mozilla. That pesky 'Close Other Tabs' should be gone now.
Please fix this! It has happened to me at least 10 times already and I'm no newbie. Especially on a slower computer if the GUI 'stutters' for a moment it is WAY to easy to click "close other tabs" instead of "close tab". You've then wiped out ALL your tabs, and AFAIK there is no way to get them back. This is especially frustrating if you are shopping or composing some text in one of the tabs you accidentally closed. Please don't put an alert asking for confirmation, that's even worse. Just seperating the two on the menu will probably suffice, alternatively, just remove the "close other tabs" option entirely. How often does the user really want to do this?
I'm sorry but it seems to me that some people here blame mozilla for the mistakes they make. "Please don't put an alert asking for confirmation, that's even worse." Why is that even worse? "This is especially frustrating if you are shopping or composing some text in one of the tabs you accidentally closed." Exactly, it was _you_ that accidentally closed the tab, not mozilla or somebody else. So why should every single mozilla user have to pay for your mistake(s)? "How often does the user really want to do this?" Well, in fact, tons of times. A lot of porn surfers asked for this feature so it was first introduced in MultiZilla. I my self use it when doing research on the web for my daily job, so it would be a bad thing to remove. My tip is: You should be more carefully in closing tabs. You are just to fast for your little left brain part. Slow down a bit and thing are fine again. Don't get frustrated right away. So you closed the wrong tab(s) ten times, well, the sky is still blue :-)
Without blaming anyone, let's look at the tool. Why is closing all tabs despised so? Because it's in a position that makes doing an irreversible act EASY. Now if you have computer problems, or something freezes (and we all know that NEVER happens, right?) you might select this without choosing to. The result? No warning, no undo, but all your tabs and all your URLS are GONE. How is that treating the user fairly? PS. Because a lot of porn surfers asked for something doesn't mean they're the same audience as the general browsing crowd. I surf with a lot of tabs open and I never, ever use close all tabs. This functionality should be: 1) removed entirely 2) be a preference 3) be part of a suite of preferences subsumed in a mode (expert mode). The general user should not be exposed to this unless he or she chooses. It's advanced functionality for a specialty market that can't be undone. Is anyone saying all users really want this? Look at this thread and its emotional intensity and then judge for yourself.
..."I'm sorry but it seems to me that some people here blame mozilla for the mistakes they make.... Exactly, it was _you_ that accidentally closed the tab, not mozilla or somebody else.... My tip is: You should be more carefully in closing tabs. You are just to fast for your little left brain part. Slow down a bit and thing are fine again. Don't get frustrated right away. So you closed the wrong tab(s) ten times, well, the sky is still blue :-)"... This is the typical open source response - "I can't figure out how to make my interface not suck, so I'll blame the user." Don't misunderstand me - whether or not it's a feature that porn surfers want is not really my concern. If it needs to be a feature, let it be a feature. The problem is that the placement of the feature is all wrong, making it WAY too easy to select the wrong menu item. Don't project the flaws of the application onto the user (and make no mistake, it is a flaw). Good interface allows the user to click as fast as they want by predictably placing menu items and widgets. This isn't it.
Before the somewhat inflammatory comment #26 starts everyone spamming this bug, I will point out #20 again, which seems to be an excellent solution (adds a close button the tab itself so one doesn't need to use the menu). As for #26... blaming it on users seems deliberately provocative. Having a bad day?
#26 - so if there was a "delete all my bookmarks" menu item _right next to_ the "delete" item of the context menu in the bookmark manager and a user with arthritus (like my grandfather who i had to teach how to use a computer from scratch) accidentally clicked _2 pixels_ to low, its their fault that all their bookmarks are trashed? sure, i'm sure you could find some users would would love to be able to clear out their boomarks quickly and easily, but this would be a really silly thing to force apon the general populous. this breaks one of the most basic tennants of UI design of not laying out dangerous, irreversable actions in close proximity to safe one.
Sure, not everybody wants to have this in the tab context menu nor does everybody likes to see it removed. So what can we do to improve the UI suck less. Fact is that a Close Icon on the tab isn't going to make it. Adding a menu separator isn't the best thing to do, but a confirmation window will make sure you don't close all tabs by accident. Let's face it, you don't see that confirmation window, if you don't use that menu item. Sure it is damn easy to select the wrong menu item, so are many others menu items but those have less effect on you. Again, we have to do something that works for both parties, the onces that like and dislike the feature. But at the end, it was still you selecting that menu item. And no, I'm not having a bad day or mind trip. We've had this discussion almost two years back now for MultiZilla and it seems to work for both parties with a confirmation window.
#30 - exactly, a confirmation window would have stopped him from accidentally erasing his bookmarks. So we should simply ask for confirmation, if there is no, simple, way of undoing the action. We are already used to this kind of confirmation windows for other programs so why not for mozilla?
"But at the end, it was still you selecting that menu item." You're still blaming the user! When we design interfaces that make it trivially easy to click on the wrong menu item, it is our screwup, not the user's. If it's not going to change, fine. Just say so, as in "I don't have time", "other bugs are higher priority", or "We don't have the technical skill". But please at least acknowledge the issue instead of pretending you've designed it "right".
#32 (i feel like we are in an episode of "the prisoner" ;) i agree, this menu needs a confirm dialog.
Why does it have to be fixed? Whats wrong with a pref to do one or both of: 1. control wether 'close all other tabs' appears on the menu 2. control wether or not there is a confirmation dialog. I would suggest the default be appear, but with the confirmation dialog. people who hate it and dont want it at all, can set the pref to hide it entirely. people who like that it blows away a whole pile of tabs at once without even a how-do-you-do, can set the pref to disable the confirmation (at least until THEY accidently lose an important URL, at which point they can adjust as needed)
clarification: I just realized I may have been unclear.. I didnt mean 'fixed' as in 'repaired', I meant 'fixed' as in 'unchangeable' Who says this feature can only work one way? There should be a pref (or two) controlling what id does, especially since there seems to be such vocally opposing viewpoints as to exactly how it should work. Mozilla CAN suit all (well, maybe at least most) users on THIS item, in fact I would say MORE prefs, and MORE documentation of those prefs.. But that is getting off the topic of this particular problem..
I am a capable and competent end user who just lost a significant amount of work to this bug because it closed a page with a text box entry where I was writing an entry onto my webpage. You can't blame this one on me; I hit the "close all other tabs" not because I'm incompetent, but because I'm *highly* competent! It should not be that easy to do something that destructive, period, especially when the destructive act is of marginal benefit. I just took the time to follow the directions in comment #19, and will do so as many times as it takes as I update Mozilla. I've closed hundreds, probably thousands of tabs, and never yet wanted "Close all other tabs". By the principle that the less used something is, the less easy it should be to get at it (leaving more room for the most frequently used commands), that pretty much says that "Close all other tabs" should either just plain *not exist*, or be buried two levels deep in the View or Tools menu or something. (For that matter, the same principle says that "Close Tab" should be on the *top* of that popup menu, at least in my case.) It should certainly not be 10 pixels away from the most common command. This is a stupid hangup; 36 comments on this bug to date and not a *single person* has defended the need for this "Close all other tabs" feature! As near as I can see, it remains of theoretical benefit to a nobody concrete, whereas the damage is real, done to real people. I suggest simply removing the damn misfeature and then worrying later, if anybody even bothers to yell for it's return, which I'd bet against.
Hey Jag, why don't you add a pref setting for this? This way you might prevent a counter action to re insert the menu item :-)
Very funny.
As always :-) Q1: can a handfull of people vote for removal of features, or do you say that every single mozilla user should visit bugzilla and vote for handy features, to prevent the removal of them?
A1: it has nothing to do with a handful of users. I as owner of this module am being the nasty dictator who says this feature is doing more harm than good and is going to be removed unless someone can convince me we really need this feature.
Comment on attachment 93290 [details] [diff] [review] Remove "Close Other Tabs" menuitem. r=caillon. Heil jag, übel führer!
Attachment #93290 - Flags: review+
Comment on attachment 93290 [details] [diff] [review] Remove "Close Other Tabs" menuitem. sr=bryner
Attachment #93290 - Flags: review+ → superreview+
Comment on attachment 93290 [details] [diff] [review] Remove "Close Other Tabs" menuitem. a=asa (on behalf of drivers) for checkin to 1.1
Attachment #93290 - Flags: approval+
Well, there goes democracy :-) Jag, I was trying to convince you, but that doesn't work for dictators as it seems. Other possible options are also mentioned here, a simple confirmation window for example, but that also doesn't work for you. So what do you need to be convinced? Eh, tell me something, how do you close 10 or more tabs?
The ability to close multiple tabs is being conflated with the placement of the "close all tabs" feature. The two are not the same. In fact, the very title of this bug proves useful -- "'close all tabs' is in a dangerous position on tab context menu." It's all about the Placement and about the fact that no warning is given the user. I concur with Justin, mozbugs, and 95% of the other posters on this thread: this feature is placed in a position that makes hurting yourself easy. Basic GUI principles state over and over again that the user shouldn't be able to perform catastrophic actions accidentally. That logic hasn't been refuted from what I've read so far. Finally, how do I close 10 tabs? I close them one at a time, making sure I've hit splat-D to bookmark the URL first.
HJ: I'll refer people to MultiZilla if they have a dire need to "Close Other Tabs" :-)
Uhm, any reason this hasn't been checked in yet?
Maybe a bit late but anyway: Wouldn't it be better to remove "close tab" instead from the context menu, since this can be achived by two other means (ctrl-w and the "close tab"-button)?
QA Contact: sairuh → pmac
I just blew away about twenty tabs with this, which reminded me of just how shocked I was the first time this happenned to me, shortly after tabs were introduced. Torben: The 'Close Tab' on the context menu is necessary to close a tab without moving it into the foreground, which (unlike 'close other tabs') is used often enough to justify its existence. The patch on this bug had sr= and a= three months ago. Any reason it's been sitting on the sidelines since?
I too am curious why this hasn't been checked in yet! Also, someone needs to change the Platform and the OS fields above. It affects Macs as well, and I still see this issue in Moz 1.2beta Mac OS 9.1.
There are ways to close all but one tab that don't involve a dangerous "close other tabs" context menu item: 1. Right-click on a tab and select "move tab to a new window" (bug 102132), or double-click a tab to do the same thing. 2. Close the original window. 1. Copy the url into a new window using Ctrl+(LC N LV). 2. Close the original window.
Re comment 53: bug 102132 has no patches and probably will not be solved for a long time Copying the URL to a new window requires lot of clicking, takes time, and will force the page to reload, so any changes made to eg a form will be lost. I think the best solution would be to have the "close tab" entry change to "close all tabs" when you hit a modifier key (eg shift on win and option on mac), the bug that prevented such behaviour should be fixed AFAIK.
I just got bit by this issue again (accidentally closed a bunch of tabs), so I thought I'd stop by and revisit it. To my surprise, it STILL hasn't been fixed. This issue to me is very simple: good GUI design tells me that it should not be so easy for the user to do something catostrophic (accidentally killing all tabs). I can only assume nobody who has the power to change this works on a laptop. If you did, you would find that it is quite easy to hit the wrong menu item when you are using a touchpad or pointer instead of a mouse. The goal is to mainstream Mozilla and to get it in front of a larger userbase, right? If so, **** like this just has to be changed. It isn't the user's fault, so stop blaming the user and blame the bad GUI that makes it so easy to screw up in the first place!
*** Bug 184024 has been marked as a duplicate of this bug. ***
Step 1 would be acknowledging the problem.
I just downloaded 1.3a. "Close other tabs" is STILL right next to "close tab". I guess no one cares that users frequently lose a whole screen of tabs to this stupid UI decision that no one can be bothered to fix.
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
Yes, please remove it.
since jag has obviously forgotten about this bug, taking.
Assignee: jaggernaut → bzbarsky
Priority: -- → P1
Summary: "close other tabs" is in a dangerous position on tab context menu → [FIX]"close other tabs" is in a dangerous position on tab context menu
Target Milestone: mozilla1.0.1 → mozilla1.3beta
Comment on attachment 93290 [details] [diff] [review] Remove "Close Other Tabs" menuitem. This patch got approved for 1.1 but never landed.... could it be reapproved for 1.3b?
Attachment #93290 - Flags: approval1.3b?
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: WONTFIX
Today is January 30, 2003. That is 14 MONTHS since this problem was first reported. It would be a very simple change to remove "close other tabs" or make some other effort to "fix" it. It is very disappointing. It is clearly a problem, yet no one cares. If you had a button that said "erase hard drive?", would you blame the user for accidentally clicking it? Of course not... so why blame the user when they accidentally click "close all tabs" ? "Close other tabs" is in a STUPID location. Please REMOVE it or otherwise make it not so easy to accidentally click.
Justin, in light of the fact that I am wasting (since I never use tabs) my time getting approval for this bug and checking this patch in, I resent the statement that "no one cares". Try not to insult people doing you a favor too much, ok? It never pays off. And for the record, if any piece of software I ever produce has a "Erase Hard Drive" button, I will damn well blame any idiot who clicks it.
Your work is greatly appreciated, do not mistake my "nagging" as an insult! It seemed to me that this was forgotten, passed over, etc. I just lost another screen of tabs tonight to this bug which brought it back to the forefront for me. Unfortunately, I'm not a coder and don't have the ability to contribute in that manner. To be frank, if by "nagging", I have generated enough interest to actually get this fixed, I sort of feel like I contributed! Would this have got done otherwise??
Yes, since your nagging had nothing to do with me noticing this bug....
Comment on attachment 93290 [details] [diff] [review] Remove "Close Other Tabs" menuitem. Thanks bz. a=asa (on behalf of drivers) for checkin to 1.3beta.
Attachment #93290 - Flags: approval1.3b? → approval1.3b+
fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
my cvs build of Phoenix for today tripped over this, since toolkit/content/widgets/tabbrowser.xml is still looking for &closeOtherTabs.label; in xpfe/global/resources/locale/en-US/tabbrowser.dtd startup error : -=-=- XML Parsing Error: undefined entity Location: jar:resource:///chrome/toolkit.jar!/content/global/widgets/tabbrowser.xml Line Number 75, Column 34: ---------------------------------^ just thought people ought to know
NOOOOOOOOOOOOO!!! Why do you have to rightclick and then choose Close Tab? Why can't you just middle click or rightclick on tab + press C or Ctrl+W or click on the close tab button on the right? I had Close Other Tabs accelerator changed from O to S (why? because left hand is on asdf and pressing S is helluva lot faster than going for the O char), rightclick on tab, press S, other tabs close. Simple and elegant. Why I want Close Other Tabs? Lets suppose new kewl Mozilla plugin is released and there are screenshots of it on the site, middle click to open the screenshots in tabs, view them, cycle back & forth between text and screenshots, well I think I've seen enough, rightclick on the text tab, press S, and the screenshots are gone, nice and fast aint it? IMHO people who "accidentally" click on close other tabs should blame their clumsy fingers or smth not bad UI design, this was perfect as it was, well to be honest the Close Tab & New Tab menu items were almost never used by me. The .diffs for making Mozilla UI usable just keep on growing... :(
I went ahead and did this on Phoenix as well, just so the XML error wouldn't happen.
Grrr. Wish I knew there was heated discussion going on about removing this feature. I think I could have had some useful input into the discussion. Too late. I use it every day, and will miss it dearly. Yes, it is dangerous (I know to my cost) but I for one find is extremely useful. Time to open an rfe bug to request is goes back in :-(
Excuse me? The module owner made a decision. This menuitem is gone. I'm not sure what you think filing a bug to reverse this decision will do, other than waste everyone's time. mkaply, thanks for fixing the phoenix bustage.
just to let you know that I miss "Close other tabs" I use it very often, and it was a useful feature to me Is there a keyboard shortcut for that, even if the context menu is gone ? It reminds me of the grippies removal ... I look forward to see this option back in very soon
OK. Enough inane spam.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
.
Assignee: bzbarsky → nobody
Status: REOPENED → NEW
.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
QA Contact: pmac → sairuh
OK. Won't open another bug... should probably see what other users think as they begin to use the new version, before considering such action. (Use the newsgroups?) P.S. As this bug is now marked fixed again, where should I post my usability findings related to this change? I don't want to waste people's time I *want* to be constructive.
Ok, apparently lots of people hate this feature, and lots of people dont want to live without it. Why is that not a good enough reason to make it a CHOOSABLE pref?!?!?!?!
It's the same problem with bug 131500 and bug 39057, though "File | Work offline" and "File | Exit" had not been removed, thx god ! Here the problem is serious, the feature has gone, it's not simply the fact that the context menu item was removed but that there's no way to achieve the same functionality ! There's no global menu option "Close other tabs" For me the correct way to go would be to keep the context menu item and add a confirmation that can be disabled ("X) Don't ask me again")
Bug 191492 filed to request the behaviour suggested in comment 54.
The people that can't live without it argue from their own personal preference, and NOT from GUI design. The fact that they type perfectly every time in no way negates the Megabytes of data lost by people who, whether distracted, or by some other accident, pressed the wrong key. Also, the "blame the user" syndrome is invoked to support functionality that causes data loss without confirmation. The latter is simply atrocious GUI design and must be noted, punishes the user for human (read: common) errors. To act as though all users never messed up and furthermore, to expect them to never mess up, because your product expects it is again, projecting the laziness of the programmer onto the characteristics of the audience. Again, unrealistic and false. None of the aforementioned arguments rest upon logic nor principle, and thus, all must be dismissed as inappropriate reasons to keep functionality that causes data loss without confirmation. You simply must back up what you see with solid logic and not emotional screeds.
Rob, if there are usability findings (as opposed to just idle speculation), they should either go in a bug (at that point a bug is appropriate) or in the netscape.public.mozilla.ui newsgroup. Thank you for taking the time to do some testing here.
There are at least 5 different ways to close a tab and now not a single one for closing the other tabs, hows that for a good usability.
Removing "Close Other Tabs" has *severly* limited the usefulness of tabs! The whole point of tabs is to easily have many of them, and also to just as easily remove then once they are no longer needed. I agree that the previous implemetation was too risky - closing all other tabs by accident was too likely. So what to do? I don't like the "modifier" idea in bug 191492 because it is undiscoverable and I've never seen context menus change with modifier keys (in windows). S U G G E S T E D S O L U T I O N: I suggest to reverse the "fix" for this bug and instead when someone (accidentally) choses "Close other Tabs" there would be a confirmation dialog (similar to when you "delete" stuff. It would be fairly unobtrusive because the user could just hit <spacebar> or <ESC> to accept or deny the confirmation. That would be sufficient safety while being discoverable and unobtrusive. Please consider this suggestion.
I'd vote for restoring Close Other Tabs and removing Close Tab as it still leaves 4 different ways to close the tab.
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.
*** Bug 191587 has been marked as a duplicate of this bug. ***
There is a discussion to fix this aweful removal of "Close Other Tabs" in the General" Newsgroup. Some of the *good examples* of why "Close Other Tabs" is useful are linked here too (just open all links in tabs using SHIFT+Middleclick, and when your done, close them all with ... oh, you can't anymore): The fitting Title: how to get "close other tabs" back !!! news://news.mozilla.org:119/3e3ae2ba$0$227$626a54ce@news.free.fr news://news.mozilla.org:119/b1hn80$lvq1@ripley.netscape.com news://news.mozilla.org:119/3e3c6e5d$0$29924$fa0fcedb@lovejoy.zen.co.uk
To all the "close other tabs" supporters - no one is saying that feature can't exist if there is desire for it. Again, the reason it's hated is not because of what is does, but because its placement makes it way too easy for the user to make a catostrophic error.
I'm against reintroducing "close all other tab", anyway i think this function is very useful, and should be restored in another way. My suggestion is: As well as "close tab" can be invoked using mid-button click on a tab, "close other tab" should be invoked using <CTRL> modifier on middle button clicking.. mid-button --> Close tab <CTRL> + mid-button --> Close all other tabs This is pretty easy to remember, and very easy to document. Also, it's elegant and safe. (the usage of a key modifier requires effort)
Thanks to this "fix" I've now lost several of the one and only window that I wanted open. I've also got hands that are cramping up after having to hit Alt-W 25 times to close all of the tabs I don't want open any more. I consider this patch a regression that needs to be removed. The right click tab menu has been the same from day one, anyone who accidentally closed all of the tabs more than once either needs a remedial reading lesson or help on using the mouse. What's it going to take to get this back?
Compromise solutions that don't involve a confirmation dialog: 1. Move "close tab" to the top of the context menu (comment 37 and bug 191826). Then it would be safer for "close other tabs" to be on the menu. "Close other tabs" could either be just below "close tab" or at the bottom of the menu. Both positions would still be somewhat dangerous. Next to "close tab" would still be somewhat dangerous because of mouse movement errors, but not as dangerous as before because you wouldn't be moving the mouse as much to reach "close tab". At the bottom would still be somewhat dangerous because scanning for a "close" command could lead you to click "close other tabs" (description error), especially if you expect the "close" command to be at the bottom of the menu. 2. Make it possible to move a tab into a new window (comment 53 and bug 102132). Then you could close other tabs in two steps: pull out the tab you want to keep, close the old window.
3. Make it possible to select multiple tabs (bug 132674). Add "Select all tabs" and "Invert selection" to the context menu, and make ctrl+click and maybe ctrl+drag add to the selection. With multiple tabs selected, "Close selected tabs" would be the first item on the context menu. (Also suggested by Rob North, comment 14.)
.
Status: RESOLVED → VERIFIED
Two things, and then I'll shut up and go away... First, the new Konqueror in kde 3.1 has a "Close Other Tabs." There's a separator between it and the "Close Tab" menu item, something worth considering I suppose... Screenshot here: http://promo.kde.org/3.1/screenshots.php?scr=3 Second, the tabbed browsing extension still includes "Close Other Tabs" so for now I'll use that. http://white.sakura.ne.jp/~piro/xul/_tabextensions.html.en
The subject of this bug is highly misleading! It mentions "dangerous position" and thus implies that the *Close Other Tabs* function should be moved to a less dangerous location. However, this bug was (unfortunately) "fixed" by removing the useful function alltogether. Suggest to either put *Close Other Tabs* back into Mozilla (there were many good suggestions how to do this while actually conforming to the bug's subject), or change to subject to reflect what this bug actually did, namely "Remove *Close Other Tabs* from tab context menu (because it is in a dangerous location for some users and we prefer not to implemet the better solutions)."
Sorry for not speaking up sooner, I haven't been reading bugmail and have had my focus on other things. The reason I didn't check this patch in is because I realized that the functionality was useful, though its place in the context menu (near "Close Tab") was dangerous. I was going to spend some time on finding a better way of providing this functionality (either by moving the menu item away from "Close Tab" or by removing it completely and providing it in the File Menu, at the loss of having an extra step because you have to first focus the tab you want to keep). Unfortunately good intentions aren't always enough. Just to clarify, I'm not at all blaming bzbarsky for checking this in; since I hadn't left any comments in this bug noting why I hadn't checked that patch in, it's quite understandable that it looked like I had just forgotten about it. I would like to change the context menu to look like this (I was thinking about leaving "Close Other Tabs" at the end, but see comment 93 and bug 191826): +------------------+ | Close Tab | | Close Other Tabs | +------------------+ | New Tab | +------------------+ | Reload Tab | | Reload All Tabs | +------------------+ I'm leaving this bug as is, please don't discuss this in here, but keep an eye on bug 191826 instead.
Jag wrote: "I would like to change the context menu to look like this (I was thinking about leaving "Close Other Tabs" at the end, but see comment 93 and bug 191826): +------------------+ | Close Tab | | Close Other Tabs | +------------------+ | New Tab | +------------------+ | Reload Tab | | Reload All Tabs | +------------------+ " That's your solution? You're just moving the problem around...
ignoring the title of this bug for just one second to clean up the whole menu. based on some usability finding we'd like to possibly add the bookmarking set. so maybe the final menu could look this way: +-----------------------------+ | Close Tab | +-----------------------------+ | New Tab | +-----------------------------+ | Bookmark this Tab | |[Bookmark this Group of Tabs]| +-----------------------------+ | Close Other Tabs | +-----------------------------+ Having the two close features at opposite ends works better because they're quicker and safer to access that way, being items which are used more frequently. I recommend removing the reload set. it's not apparent why reload is needed in a tab context menu, or why user wouldn't just click on the reload button in the toolbar which is already familiar. i think the reload toolbar button is extremely visible. [Reload all tabs] should be in the [View] main menu in addition to or in place of the context menu.
All of the suggested positions for this item still leave it easy to hit by mistake, because in all cases it is next to something non-destructive. (A single separator bar is not adequate separation given the imprecision of most consumer pointing devices.) The only real solution for putting it back safely is a confirmation dialog. (There will still be users who frob "Yes" and then wish they hadn't, but there's no help for that. A misclick is unavoidable in many cases, and we can help by confirming; a misthink has to be the user's responsibility.) That does add an extra action (click or keypress) to the process of closing all tabs, but the added action is constant, regardless of the number of tabs so closed, so in cases where the user is closing large numbers of tabs it would still be a very significant shortcut over closing each tab individually. But putting the feature back in without confirmation would lead to DATALOSS, which is why this bug was filed in the first place. It is also notable that all (err, both) of the people who said they don't want a confirmation dialog also don't use the close-all-tabs feature. (Neither, as far as that goes, do I; I close each tab when I'm finished with it.) As near as I can determine, the people who want it back would be willing to click a single confirm button in exchange for not having to close many tabs individually. The other way to go is a pref; that would be fine with me too, but you will find other people who are against adding prefs.
Yes, a confirmation would be superior to a menuitem for *Close Other Tabs*. Confirmation: 2 clicks (*at* the mouse location): Close other > OK Menuitem: 2 clicks (*away from* curser loc.): File > Close Other Tabs +-- Close Other Tabs? ----------------------------------+ | | | Do you really want to close the other tabs? | | Closing Other Tabs will loose all data in those tabs. | | | | [ ] Don't ask me this again | | | | [[ yes ]] [ no ] | +-------------------------------------------------------+
Terribly sad to lose this very useful functionality. Perhaps this could be opened as a separate vote item?
Reopening. With the fix for bug 191826, things are now, IMO, *worse* than they were before. Not only is Close Other Tabs back underneath Close Tabs again (actually, I don't mind that but this bug does) but now both are at the TOP of the context menu. Not only is it now easier to click on Close Other Tabs (because it's closer to where your mouse is after a right-click) but it's also easier to click on Close Tabs by mistake. Any argument about accidental dataloss is now even stronger than before.
Status: VERIFIED → REOPENED
Keywords: regression
Resolution: FIXED → ---
As I see it, there are two issues here. 1. The fact that Close All Tabs is right next to Close tabs. That has not been fixed by bug 191826 - now both have been moved (in their same relative position) to the top of the menu rather than the bottom, where they were originally. 2. It's too easy to click on a "close" option because it's either at the top of bottom of the list. So, a proposal to fix *both* of these issues, and to also keep functions as consistent as possible, would be: +------------------+ | New Tab | | Close Tab | | Reload Tab | +------------------+ | Close Other Tabs | | | Reload All Tabs | +------------------+ Single tab actions are at the top, multiple tab actions are at the bottom; Neither the topmost *nor* the bottom-most entry does anything descructive; *AND* Close All Tabs is no longer located next to Close Tabs.
This also follows the "menu item standard" of having New/Open at the top and Close/Exit at the bottom. Since "Reload" is something that doesn't appear in the regular menus, it's isn't going to go against any convention to put it where we want.
Well, to have New/Open at the top and Close/Exit at the bottom, it should look like this: +------------------+ | New Tab | | Reload Tab | | Close Tab | +------------------+ | Reload All Tabs | | Close Other Tabs | +------------------+
The suggestions in comment #100, comment #105, and comment #107 all pull related functions ("close", "reload") apart, thus making the layout disjointed and confusing. My preferred solution is as suggested in bug 191826 comment #8: +------------------+ | New Tab | +------------------+ | Close Tab | | Close Other Tabs | +------------------+ | Reload Tab | | Reload All Tabs | +------------------+ In any case, just about every conceivable combination has now been suggested.
> ...all pull related functions ("close", "reload") apart, thus making the layout > disjointed and confusing. It is the goal of this bug to pull those related functions ("close" and "close other") apart. Otherwise it would be best to leave the menu as it has been all the time (up to 1.2.1).
Please re-read comment 105. Stefan: Your solution has "Close Other Tabs" at the bottom which "exposes" it to a jerk of the hand. (It's much easier to select something at the top of a list or the bottom of a list, than it is to select something buried in the middle of a list.) While I understand the desire to remain in keeping with other menu components that have close/exit at the bottom, I think that it's a matter of the lesser of two evils, and preventing accidental dataloss is more important here than being 100% strict in terms of that positioning. Peter: Your solution does not separate "Close Tab" from "Close Other Tabs" - one is still right below the other. This also is what many people here are complaining about because when they are "aiming" for "Close Tab" they hit "Close Other Tabs" by mistake. Further, comment 105 and comment 106 do not pull functions apart - they just group them logically in a different way: all single tab actions at the top, all multiple tab actions at the bottom. In fact, depending on how you look at it, it's more logical to do it that way.
> Your solution has "Close Other Tabs" at the bottom which "exposes" it to > a jerk of the hand. I dont't think so. The only way to open this menu is right-clicking onto the tab bar, isn't it? The tab bar is located at the top of the browser window, therefore the menu will always open below the mouse cursor. So it is easy to hit the topmost menu entry by mistake, but not the last one.
Remove "Close other tabs" because someone may click it by error is as stupid as remove close window button [X] because someone may click it when trying to maximize de window. It's better to teach all mousetupid people to close tabs pressing Ctrl + F4 or clicking the button at end of tabs row.
> So it is easy to hit the topmost menu entry by mistake, but > not the last one. It's easier to hit either the top OR the bottom item than it is to hit something in the middle. > Remove "Close other tabs" because someone may click it by error I don't think that this bug is advocating the removal of the context menu item (although it was once resolved that way - to much dissension) - just moving to a less dangerous position within the menu.
QA Contact: sairuh → nobody
Removing "[FIX]" in summary as it no longer applies.
Summary: [FIX]"close other tabs" is in a dangerous position on tab context menu → "close other tabs" is in a dangerous position on tab context menu
With the resolution of bug 195486, and what should (now) be the logical resolution of bug 177397, I'm revising the context menu I proposed in comment 105 to the following, which can now place "close" more toward the traditional end-point of the menu (all previous justications still apply): +-----------------------------+ | New Tab | | Reload Tab | | Close Tab | | Bookmark Tab | +-----------------------------+ | Reload All Tabs | | Close Other Tabs | | Bookmark This Group of Tabs | +-----------------------------+
RE comment #115: Please no! From the users' standpoint grouping by "all vs one" is less relevant than grouping by "close vs reload vs bookmark". The user is thinking "close tab" before thinking "all".
I have yet to see any other suggestion that groups the functions in a logical fashion, while keeping in mind the following: 1. Close and Close Other should not be next to each other. 2. Neither Close nor Close Other should be in the top-most or bottom-most position. Remember - this bug is about preventing dataloss. I would think that anybody who's following this bug on that basis would find THAT the most important priority here. Grouping should be secondary.
> 1. The fact that Close All Tabs is right next to Close tabs. That has not > been fixed by bug 191826 - now both have been moved (in their same relative > position to the top of the menu rather than the bottom, where they were > originally. Are you (or someone else) actually clicking "Close Other Tabs" in its current position while trying to click "Close Tab", or are you just speculating? While "Close Other Tabs" and "Close Tabs" are slightly closer than they were before, the ratio of the distances from the corner of the context menu to "Close Other Tabs" and "Close Tab" and is now much larger. > 2. It's too easy to click on a "close" option because it's either at the top > of bottom of the list. It *should* be easy to click "Close Tab". It's by far the most useful command on the tab context menu, and it's also "more context-sensitive" than most of the other commands in the menu. By the way, I don't think "easy to click" is always the same as "easy to click accidentally".
Here's a quote from comment 0 - the reason that this bug was filed in the first place: "Having two actions with destuctively oposite effects right next to each other is not a good idea. Many times I have accidentally clicked "Close Other Tabs" when intending "Close Tab" The reporter of this bug intended that Close Tab and Close Other Tabs not appear vertically adjacent to each other. What I'm saying is that any patch that purports to "fix" this particular bug, has to address the issue around which the bug was specifically filed (making "Close Tab" and "Close Other Tabs" NOT be right next to each other). Other considerations can/should also apply, but one requirement of resolving the bug as originally reported is just that. > Are you (or someone else) actually clicking "Close Other Tabs" in its > current position while trying to click "Close Tab", or are you just > speculating? Personally, I've never accidentally clicked Close Other Tabs, regardless of *how* the context menus have been arranged. I have no *personal* stake in this bug at all. (Although I do have a passing interest in how the context menus should look.) However, I am trying to keep it on course in terms of its entry in the Bugzilla database. > It *should* be easy to click "Close Tab". Perhaps. (Although, what we want to do here is *not* make dataloss easy. I'm sure that people could argue that even the single "Close Tab", while being the most likely thing people select, should still not be the easiest.) However, that's not the main point here. The main point is that it *shouldn't* be easy to click "Close Other Tabs" - and especially not easy to do so when somebody's intention is to click *only* "Close Tab". (Clicking the other by mistake causes the exact opposite of the behaviour that was originally intended.) > I don't think "easy to click" is always the same as "easy to click > accidentally" Perhaps not. If "Close Tab" were at the very top (as it currently is) and "Close Other Tabs" were at the very bottom it would be almost impossible to "accidentally" click on one when intending the other. It would still be easy to click on "Close Other Tabs" but it would be a lot less accidental than it is currently when both are sitting right next to each other. An argument in favour of the sectioning off of Single vs. All tab functions is that it makes you have to really think about what you're doing. It's almost impossible to accidentally click on a single vs. all function by mistake - and the all tab functions, which hold the greatest possibility of dire consequences, are the least likely to be hit on by mistake if the "ones at your fingertips" are all only single tab related.
+-----------------------------+ | Close Tab | +-----------------------------+ | New Tab | | Reload Tab | | Bookmark Tab | +-----------------------------+ | Close Other Tabs | | Reload All Tabs | | Bookmark This Group of Tabs | +-----------------------------+ At the risk of adding yet another combination I personally prefer this. I most often use close tab; this is the most accessable position for it, yet separated off so I shouldn't hit it by mistake. I *have* hit 'Close Other' by mistake (please, if you quickly click on something it can be done, ok!) - therefore I agree that its a bit dangerous next to Close Tab. Personally I would also like it to a have a confirmation box as talked about before as its such a destructive option. This layout separates single and all actions and IMHO into one that I would hit by mistake least! I also liked the submenu suggestion in bug 191826, comment 9
Aaaack!! Put it back! Having "Close Tab" at the top, where "New tab" was has totally thrown me (and I'm sure many others) completely off! The "new tab" button is way too far over to the left to be useful to me (a right-side centric browser), so now I have to hunt around after the "new tab" menu item, frustrated that a good tab has been closed. Is there a different bug for this ordering? I'd love to vote to get it put back the way it was pre-1.3.
If nobody actually has a problem with Close Tab at the top, and people think that, despite possible dataloss, the most frequently used command *should* be at the top, then comment 120 seems reasonable. The original layout didn't work, so whatever we come up with will be different than it was. This is as good as any.
comment 120 does not seem reasonable. And there IS indeed a problem with the close item at top of the context menu. It simply doesn't belong there. It is NOT the most important thing you do with a tab. Before you can close a tab, you have to OPEN a tab. Thus: The very first item should logically be "New tab" - just like the "New" item is the first item in the File menu on browser menubar.
> Before you can close a tab, you have to OPEN a tab. In my browsing experience, 95% of the time that I open a new tab it's by doing a Ctrl-click on a link. (AFAIK, I've never *once* used the tab context menu to open a new tab - rather I use the new tab button at the left of the tab bar or hit Ctrl-T.) Also, 99% of the time that I've actually used the tab context menus it's been to close a tab different from the one that I'm actually viewing. So, in my experience anyway, Close Tab is definitely the most important thing I do the tab context menu. (Which is, BTW, quite different from the most important thing I do with tabs in general.)
Why does everybody consider the "close tab" option to be the most important? You can close a tab with a middle mouse click. I've never used the context menu to close a tab... ;-) I think it is wrong to sort menu entries by the frequency they are used. Not to mention that everybody has its own opinion about what is the most frequently used command. The menu entries should have a logical order according to common GUI design conventions. That means: "new" at the top, "close" at the bottom. I've never seen a single menu having "close/exit" at the top. The intention of this bug was to separate "close" from "close other". This can be done by grouping into single-tab and multiple-tab sections. So I would prefer +-----------------------------+ | New Tab | | Reload Tab | | Bookmark Tab | | Close Tab | +-----------------------------+ | Reload All Tabs | | Bookmark This Group of Tabs | | Close Other Tabs | +-----------------------------+ Or, alternatively, the suggestion from comment #115, if Jason thinks it is too dangerous to have "close other" at the very bottom.
> The intention of this bug was to separate "close" from "close other". Agreed. That is the single-most important thing here. *This* bug could be resolved as fixed (although no doubt another one would be opened, albeit one without a dataloss keyword) if we simply took the existing existing context menu and bumped Close Other Tabs down two places. We shouldn't get too hung up on precise layout here. (Particularly since it seems it's impossible to come to a concensus.)
I agree with comment #121 - I use the right-click route to new tabs all the time when opening a bunch of bookmarks. Having "Close" means it's much more difficult to do that (i.e. you actually have to look to make sure you hit the right menu item). I've changed my toolkit.jar back to make "New" be at the top once more - much easier to use.
Dare I raise the "All Tabs" submenu discussion again? It was mentioned in bug 191826 comment 9, and I also made an aborted attempt to introduce it in bug 191587 at a time when the only "all tab" action was "reload" - so closed it myself since it made no sense during the current menus. Now, however, the picture has change since there are currently 3 "all tab" actions allowed and it would seem to make sense again. Since it's obvious that "what is the most commonly used item" is *not* objective, there's little point in doing anything other than sticking with the commonly accepted standard for menu items, with new/open at the top and close/exit at the bottom. I think it also makes sense to group the "dataloss" functions close and reload. So: +-------------------+ | New Tab | +-------------------+ | Bookmark This Tab | +-------------------+ | Reload Tab | | Close Tab | +-------------------+ | All Tabs > |+-----------------------------+ +-------------------+| Bookmark This Group of Tabs | +-----------------------------+ | Reload All Tabs | | Close Other Tabs | +-----------------------------+ I can't imagine anybody accidentally losing data with this in place.
*** Bug 198045 has been marked as a duplicate of this bug. ***
How about making "close other tabs" an undoable operation, as it should be since it's so destructive. Then if you did the wrong one (as I do all the time, which finally brought me here), it would be a simple matter to restore your settings. That should be done regardless, since even with physical space between the menus, it still certainly possible to make a mistake. And it's far less obstrusive and won't be ignored like a confirmation dialog box would be.
If the intent of this bug is to separate "Close Tab" and "Close Other Tabs" then WONTFIX.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
I'll confirm that that was the intent, and also verify the module owner resolution given that. (Further discussion will have to take place outside of this bug.)
Status: RESOLVED → VERIFIED
Okay fair enough, splitting the options doesn't look great. However how would I go about getting bug 191578 (Confirmation box for close other tabs) reopened? This would seem to solve (at least for me) the problem - possible dataloss.
So would it be necessary to open a new bug to get "New Tab" put back at the top of the list?
I love being able to have multiple tabs open, and i use them all the time. It drives me crazy when I lose 10 tabs by accidentally hitting the "Close Other Tabs" button. I probably hit it accidentally 1 out of every 100 times I'm going for the "Close Tab" button. Probably once every other day or so. Not all the time, but frequently enough to be a serious usability problem. That said, it's apparent from this thread that attempts to fix this interface problem are in deadlock. My suggestion: Why not enable Undo for "Close other Tabs". So when the user accidentally invokes the "Close other Tabs" feature, s/he can just ctrl-z to restore all of them. This enables people who love the "Close other Tabs" feature to keep it just the way it is, and users who invoke it accidently have a way to restore their context.
*** Bug 204323 has been marked as a duplicate of this bug. ***
*** Bug 207134 has been marked as a duplicate of this bug. ***
*** Bug 199803 has been marked as a duplicate of this bug. ***
*** Bug 211522 has been marked as a duplicate of this bug. ***
Since the layout is now unacceptable to a wide array of users, could a pref be added to order the menu as the user chooses, a la OpenOffice.org? I've been manually editing the XUL file to put it back in a usable order (for me) each time I upgrade Mozilla, which I've been doing far less frequently due to the hassle.
Good news: there's now a confirmation dialog preference, at least for window closing. See Bug 218517, Bug 191578. browser.tabs.warnOnClose exists and defaults to true in browsers after 1.4.
I still lose data because of this. STILL.
*** Bug 228552 has been marked as a duplicate of this bug. ***
*** Bug 229525 has been marked as a duplicate of this bug. ***
*** Bug 236383 has been marked as a duplicate of this bug. ***
mozilla/toolkit/content/widgets/tabbrowser.xml includes a separator between Close Tab and Close Other Tabs as of CVS version 1.22. The fix is still in as of Mozilla 1.7a, which is nice. It would be nicer if they were at opposite ends of the menu, but at least they're not actually directly adjacent anymore. Maybe this could be tagged as fixed; in any case, it's pretty damn user-hostile to tag something like this WONTFIX.
Personally, I don't consider that putting a separator is the right fix. I don't understand what is the big problem to put the two options on opposite sides of the popup menu, this is how was on previous versions of Mozilla (don't remember exactly what version...) Regards, Lucas
I've got a trivial local patch that just changes the context menu to go like this: Close Tab Reload Tab New Tab ==== Bookmark This Group Of Tabs Reload All Tabs Close All Tabs I'm a newbie here, but a bug that's this old and marked WONTFIX makes me think it isn't worth the trouble of jumping through the appropriate hoops to get a patch work. Am I wrong?
I stand behind comment #140. A small pref would make this bug die forever.
A pref would satisfy you and me, but I don't think the set of users who are willing to edit obscure prefs is that much bigger than the set of users who are willing to edit XUL, and I don't think it includes anything like a majority of the people who are getting screwed by this bug a few times a week each.
*** Bug 242664 has been marked as a duplicate of this bug. ***
*** Bug 246684 has been marked as a duplicate of this bug. ***
*** Bug 247502 has been marked as a duplicate of this bug. ***
*** Bug 265057 has been marked as a duplicate of this bug. ***
*** Bug 308141 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: