Pressing Ctrl-W or any other close shortcut in a multi-tabbed window will close the entire window with no warning. This may cause users to lose track of visited websites and shown data, when they forgot they had more tabs. I suggest adding an optional confirmation dialog when closing a tabbed window. BTW: Does this happen with javascript window.close()? I'm using Build 2001110708 on Linux.

This is not a dup of bug 103452. I'm talking about user-initiated window-close.

ctrl-w closes the current tab, for me, linux 11/07 build.

The same should apply to the regular "X" for the browser window itself. If this is to prevent accidentally exiting the browser window, rather than the tabbed browser window, I can say that I've frequenly, out of habit from historically browsing in separate windows rather than tabs, exited Mozilla itself when I've finished viewing a site. This has resulted in much cursing at myself after realizing I should have clicked on the tab "X" rather than the main "X".

Status Whiteboard comments: If this is a duplicate it should be marked as such, and closed. If not, the comments should be removed.

Unable to find duplicate in Tabbed Browser component, maybe the dupe is in the wrong component? This is _similar_ to the RFE about the "Close All Tabs" item on the context menu, but not quite the same thing.

*** Bug 109817 has been marked as a duplicate of this bug. ***

confirming since no duplicates seem to be around.

*** Bug 111021 has been marked as a duplicate of this bug. ***

This seems like a silly workaround.

I'm not sure what you mean by "silly workaround?" I think konsole handles this appropriately... Maybe add a checkbox that says "never show this warning again." ____________________________________________________________ | | | You have open sessions (besides this current one). | | These will be killed if you continue. | | | | Are you sure you want to quit? | | | | Yes No | _____________________________________________________________

*** Bug 117557 has been marked as a duplicate of this bug. ***

ccing some UI people. We need a spec before we go off and implement this.

Ctrl-W just closes tabs on Windows, why is Linux different? Other than that, I don't see any defect here. When users command us to close the window, the only reason to interrupt that command is to offer save unsaved work (and IMO, even that should be done away with in favor of saving everything always, like PDAs).

> Other than that, I don't see any defect here. When users command us to close > the window, the only reason to interrupt that command is to offer save unsaved > work (and IMO, even that should be done away with in favor of saving everything > always, like PDAs). The point is that people somtimes close the entire window rather than just the current tab. (Whether they do so by "Ctrl-W" or some other method.) They either forget that they have other tabs open, or they do realise it but forget that issuing the command to close the window will do more than close just the current tab. Having a "You have other tabs open. Are you sure you want to exit Mozilla?" warning message will help in these situations. I don't know what you mean by automatically saving unsaved work. So if you close everything accidentally you can run Mozilla again and it will return to its pre-exit state, with all tabs and windows, all scrolled to where they were before? I believe that this is a separate bug and would require far more work than a simple warning. (It would also be more of a nuisance to the user to start up Mozilla again, than to not have exited it accidentally in the first place.)

*** Bug 121056 has been marked as a duplicate of this bug. ***

Reassigning to new component owner.

I just want to say that I would like to see a confirmation as well. I love the tabbed interface, but I too will hit the big "X" in the corner by accident. In lieu of a dialog box, I'll suggest a behavior that would surely bug some UI designers for who prefer foolish consistencys (... is the hobgoblin...). That's to change the behavior of the "X" from close window to close tab whenever there is more than one tab present.

I agree with the originator and comment 3. I am often scared that I'll accidentally press the X in the upper-right corner and close the entire browser rather than the tab. I would like some sort of prompt to ensure that this wasn't accidental. I do not think that the upper-right X should close only the current tab, and so I disagree with the suggestion in comment 17. (Why else do we already have a separate X for tabs?)

*** Bug 127438 has been marked as a duplicate of this bug. ***

*** Bug 133122 has been marked as a duplicate of this bug. ***

*** Bug 133178 has been marked as a duplicate of this bug. ***

*** Bug 137146 has been marked as a duplicate of this bug. ***

*** Bug 137238 has been marked as a duplicate of this bug. ***

I also agree with comment 3... such a behavior should be familiar to most users. Another example would be, say, MS office with multiple _unsaved_ documents open - just closing it will prompt a warning so you dont lose work. With a browser, the work being lost could be time spent searching or reading a long article. I disagree with comment 17 (partly since I've never seen an application that does it that way)

I agree with comment 24. In addition, this is a BIG problem when using weblogs such as http://fisheye.co.il where "new" messages are marked by page loads, and closing a page by mistake will lead to loss of new/old distinction. About finding a page, a workaround is to use the history. However, your location in the document will still be lost.

The suggestion in comment #17 is probably not even possible on some platforms.

I don't think we can reasonably consider any viewed document to be 'unsaved' in the same sense as documents in other programs that have been explicitly opened for editing, modified, but not yet saved. We already keep a history reference to all viewed documents, so you can return to them if you didn't mean to close them. Adding such a confirmation would mean getting a warning dialog whenever closing the browser, unless you first closed all tabs. We could reasonably consider treating active, modified forms as unsaved work, but search results seems a bit of a stretch, since they are quite reproducible. There are also some squirrely issues with forms that are left in the session history, but not currently active. Also, such a change should apply similarly to windows, not just tabs, since the same principles are involved. cc marlon for UE input.

Well, as a user I can tell you that I frequently will have move than one window open... And usually one window that has a few tabs. If after a few hours of work I look down at my taskbar and see 15 windows open, I'll naturally start cycling through and closing them. All too often I close a window that had a few tabs open and some junk on top... Like I commented before, I do the exact same thing with konsole, and it's saved me some time to recover a window where I had a lot of tabs open. If mozilla only existed in one window, I might agree, but since you can have many windows, some with tabs and some without... It makes sense that someone might try to close a window that they thought was garbage, only to realize 2 seconds later that they had 10 tabs open in that window

Hmmm. So, how do you close all those windows? It seems like Ctrl-W would be a good fit for your usage pattern, since it cycles through each tab before closing the window. You say you'd like to get a confirmation dialog, but people are generally poor at predicting what they'd actually use, or how they would react to it (even though we all *know* that we personally are good at it ;-). Confirmation dialogs that are usually dismissed are especially bad, because people become habituated to them, and eventually dismiss them without even thinking about it, thus making them merely a nuisance. I remember back in the early days of DOS, many commands would put up an inane "Are you sure?" dialog, sometimes even followed by another "Are you really sure?" (I am not making this up). What was really needed in most of these cases was a way to recover in the unlikely event the command was not intended. Perhaps that is what is needed here. What if you could somehow get the window back, with tabs, perhaps by clicking on a bookmark group in history? Would that be sufficient?

perhaps, but I think the difference between an "are you sure" command and this is that this only occurs when you have multiple tabs open. If I'm cycling through a bunch of windows clicking the "X" up top, the notification would (should) be unique to windows with tabs open so that the user would be signaled... They probably wouldn't become desensitised to it that way. It's proabably also reasonable to put a checkbox that says "don't show this warning again." I understand where you're coming from with notification boxes being annoying, but I think the impact on those that don't need such a notification would be minimal if they could turn it off the first time it happened. Just my $.02

Why aren't you using Ctrl-W, if you want to see all tabs before they are closed? My take on the 'don't show me this again' checkbox is that it is all too frequently used to justify an unnecessary first imposition, and there are all too many users who are reluctant to check the box, so they just suffer. The ones who do check it are faced with the same problem that caused it to be added, and no way to recover, so the next proposal is invariably that a UI pref be added to reset the checkbox. Through hundreds of such decisions over the years, we now have an overly complex, bloated browser. Perhaps this is one of the few cases where this is justified, but I'm inclined to push back on nearly all such proposals, lest we accept the frivolous ones too easily.

Well, I don't think I've ever used ctrl-w... when I'm clicking things on the taskbar to maximize them, I'd have to move my hands onto the keyboard... I could probably try ctrl-w for closing windows, that would mean an effort to remember to use that special method of closing windows for mozilla only, since it doesn't work for any other applications (I just tested with konqueror). I'll give it a try though. I can only say that this exact feature of konsole saves me all the time; perhaps I've just become accustomed to it. Anyway, it won't break my heart if this isn't implemented, I personally just shy away from using tabs in mozilla because of this very reason.

Suggested alternate feature from comment #29 submitted as Bug #137481.

Perhaps all the close affordances should be changed to mean 'close tab' when there are mulitple tabs? We are being a bit inconsistent here as it is.

trudelle: would that mean that if a pr0n window (from say a pr0napped domain) triggered twenty new tabs, i'd have to close each tab by hand (risking new tabs as they focus)?

Let me see if I can review here. 1. Why not use Ctrl-W? This was answered early on in the thread. Not only have a lot of people never used Ctrl-W before (why change browsing habits just for this bug) but the confirmation should apply to EVERY (normal) method of exiting the browser. The same reason against just sticking with Ctrl-W is the same reason why having the smaller, Tab X is insufficient. The big main X still exists and is sometimes clicked on by mistake. 2. Confirmation dialogues that are usually dismissed are bad. Typically, I always close all tabs before I exit the browser. It's only when I *mistakenly* click on the main X, rather than the Tab X, that all are closed at once. The point of this bug is to prevent such mistakes. Therefore, at least with my browsing pattern, I wouldn't usually dismiss the dialogue. I'd normally use it because if it showed up I'd clicked somewhere I shouldn't have by accident and it would be useful to me. I don't know if other people normally (and intentionally) exit the browser with multiple windows open more often than closing each of them prior to exiting. Something tells me that they wouldn't, but I'm no authority here. 3. Don't show me this again checkbox is a first-time imposition. I'm not sure I agree with this but, let's say I do. Since having the option of not showing the dialogue would obviously be a preference, then make the default setting be to NOT show the confirmation window. That way there *is* no first-time imposition and those who *do* wish to see the dialogue can turn it on. Everybody's happy. 4. An alternative to adding "yet another pref", which you seem to be against for reasons I can understand in general, is to modify the behaviour of the main X button. Have it close the current tab (as the small one does now - I know this would make the small one redundant, so perhaps it should be removed if this is implemented) if clicked on normally and only exit the browser completely if you do a <Ctrl> click on it.

============== I don't think we can reasonably consider any viewed document to be 'unsaved' in the same sense as documents in other programs that have been explicitly opened for editing, modified, but not yet saved. We already keep a history reference to all viewed documents, so you can return to them if you didn't mean to close them. ============== Just asking here because I'm unsure (though I think the answer is negative) ... does going to a document in the history reestablish cookie settings and/or referers and/or other items that would make the history stateful? If not, then history is not an adequate answer here. ============== Adding such a confirmation would mean getting a warning dialog whenever closing the browser, unless you first closed all tabs. We could reasonably ============== Not the behavior I think some have requested ... at least myself on a duplicate bug. I don't want to see the dialog box if I hit the main [X] when there is only 1 tab open. That should behave the same as closing a normal non-tabbed window. I still will nail myself on this on occasion, but not nearly as often and I have this same issue with all browsers so it is a common behavior. This means people not using tabs will never ever see the "do you really want to close all tabs" dialog, hence the -standard- behavior (at least until tabs take over the world) will remain status quo. However, if I hit the main [X] and there are multiple tabs open, then adding a dialog here does not change a standard behavior because there is not yet an accepted standard for tabs (unless you view them as MDI [multiple document interface] windows, in which case there is a standard, and we don't follow it, to ask before closing multiple MDI windows). Additionally, I've mentioned in the duplicate bug that I don't care if the dialog is active when I install Mozilla, make it a pref under the tabbed brower preferences. Leave it off by default. ============== consider treating active, modified forms as unsaved work, but search results seems a bit of a stretch, since they are quite reproducible. There are also some squirrely issues with forms that are left in the session history, but not ============== This adds a set of code that encompasses saving forms and all of the security and data issues that accompany it just to avoid adding a dialog to the interface. And even then, I see needing a pref for this for security reasons. No net gain for this direction in my mind (though being able to save unsubmitted forms could be an attractive feature elsewhere, but generally I would be against it). ============== currently active. Also, such a change should apply similarly to windows, not just tabs, since the same principles are involved. cc marlon for UE input. ============== I don't see this. Separate windows would only need a dialog -if- they also had multiple tabs and if somehow I had tried to close them. Generally speaking, if I accidentally close one window with tabs, it won't affect others (unless I've tried to kill all processes instead of clicking [X] in the UI). NOTES: * On the "just use ^W" thread ... because that's not what many people use. The desire is to get Mozilla to be friendly to mouse interface users. * Regarding having the [X] button only close 1 tab at a time ... this again is deviant from what people expect out of a multiple document interface. Also, I strongly agree that it has problems when it comes to pagez that are scripted to behave badly on purpose (pr0n, etc). * I don't believe we can adequately determine what windows have been viewed ("saved") versus what have not ("unsaved") unless we start tracking tab clicks to determine if that tab has been raised to the foreground. Even if it has, often I am working in a tab for hours trying to keep a page up for documentation, etc and I would still desire the dialog even on view ("saved") pages. * Summary of what I personally would like to see ... I don't expect to get exactly what I want, but it doesn't hurt to be explicit: - the main [X] that currently closes all tabs would, if and only if there are multiple tabs open, confirm that you want to close the entire browsing window. - main [X] would behave as today if only a single "tab" / document is open, keeping behavior standard with other browsers. - other windows would be unaffected by the main [X] so nothing needed there - small tab [X] still works as expected

timeless: no, we already provide an explicit 'close window', I'm just speculating on whether we'd want 'close' to be interpreted as 'close tab', as we currently do for Ctrl-W. jason: I wasn't suggesting that Ctrl-W is a solution for everyone, I was asking if it fit one person's usage pattern. Having any solution to this be off by default would mean that few people would get any benefit from it. If we do anything here, I hope it would fit typical usage well enough to be enabled by default. I haven't heard anyone say that explicit close window commands other than 'the big X' should put up a confirmation dialog, though I don't see any justification for being inconsistent here either. Nominating for MachV & mozilla1.0.1. Certainly too late for 1.0/beta, but there seems to be a substantial issue here, and we should consider it, track it, and resolve it if necessary. It will be good to get feedback from typical users, which none of us are. As for the rest, this is getting out of hand for a bug report. Once people start posting page long comments where they quote other comments at length, the discussion should be moved to the newsgroups.

keep in mind this case will not be met by non-tab users, however, it is troublesome for tab/combo users. since it occurs so commonly and in a distinct situation it qualifies for both a warning and pref. I suggest that we produce a dialog which would force a decision of one behavior over another on a user (to overcome user predetermination to close anything and everything), with of course, a safe setting for default (Seperate Windows). ___________________________________________________________________________ The window you are about to close contains [8] web page(s) contained in page tab(s). To avoid losing these web pages when you close the window you may seperate them into individual windows by hitting "Seperate Windows", or, hit "Close This Window" to close the window and all of its page tabs. You can check "Remember My Preference" to avoid this warning next time. You can always change this setting later in the Tab Browser Preferences. [ ] Remember My Preference [Seperate Windows] Close The Window ___________________________________________________________________________ The 'Seperate Windows' idea is just something that came to mind. It will close the currently viewed tab, but all other background tabs will spawn in cascaded windows. i don't mind hearing other suggestions, however, we do need to provide some safe level default and a warning, and possibly a preference depending on how we end up handling it.

I don't know if I like the idea of spawning windows, I don't know if I really see a point. If they had wanted separate windows, they never would have opened tabs in the first place. I think that might warrant a separate bug report. For the record, I also think that changing the behavior of the "big X" in the window decoration would be a huge mistake. I'm sure almost all UI/usability people would agree. It's all about intuitive, expected behavior

I don't understand what pref the system would be remembering, how does hitting either of the other buttons express a pref that is valid for other windows? Also, if we do add a confirmation, shouldn't there be a way to cancel the the close?

See comment 10, add a checkbox that says "never show this again"

Nick: it is less a question of whether users intend pages to be in windows vs tabs, and more about the anonymity of closing and losing pages that aren't presently in view. Separating pages into different windows allows the user: 1) the opportunity to view and close each page in window fashion, while 2) still obey the user intent to close the current page (thereby not breaking from window convention) - it is for the fact that users forget about remaining background pages that we're discussing this problem in the first place. I agree that we shouldn't break window conventions, because i would like to see tabs and windows peacefully coexist. However there aren't many applications which handle the problem of multiple document interface in tab fashion to base our behavior on. So with the dialog/feature i am proposing we: 1) obey window closing conventions everytime 2) Do something safe by default, and allow user to customize to get more speed and convenience which comes with a price of multi-page losses I agree it may be somewhat unusual solution, but it does meet some requirements. I would add a [Cancel] button to the right side, from Peter's suggestion: ___________________________________________________________________________ The window you are about to close contains [8] web page(s) contained in page tab(s). To avoid losing these web pages when you close the window you may seperate them into individual windows by hitting "Seperate Windows", or, hit "Close This Window" to close the window and all of its page tabs. You can check "Remember This Preference" to avoid this warning next time. You can always change this setting later in the Tab Browser Preferences [ ] Remember This Preference [Seperate Windows] Close The Window Cancel ___________________________________________________________________________

I'm still not sure what pref would be remembered. If I checked the box, then clicked Separate, would subsequent close of multi-tab windows cause them to break up into separate windows instead? What if I checked it and then clicked Cancel? What about the case where the user Exits while windows are minimized? That would seem to fit the same pattern (closing pages not in view). Also, I believe there is a large performance cost to opening all the pages in a new window.

>I'm still not sure what pref would be remembered. If I checked the box, then >clicked Separate, would subsequent close of multi-tab windows cause them to >break up into separate windows instead? yes it would break them out, but it would also close the page that were in view at the time of the close. >What if I checked it and then clicked Cancel? then you are weird ;) my guess is that we should either ignore the checkbox, or disable the cancel button if they click the checkbox. >What about the case where the user Exits while windows are minimized? that's a very different case, the user doesn't care about any open windows when they exit, so it wouldn't be any different now. I'd am in favor of remembering state like Opera does, but let's discuss that down the road. >Also, I believe there is a large performance cost to opening all the pages in a new window. You're right. If we had a different new-window story then it might be something to consider, however, perhaps we stick with a simple question like Comment 10 ___________________________________________________________________________ ? The window you are about to close contains [8] web page(s) contained in page tab(s). Hit, "Close Window" to close the window and tabs within it. To close only the current page try clicking the close button on the Tab Bar, or using shift+ctrl+w. Select the checkbox, "Do not warn again" to avoid this warning. [ ] Do not warn again [Close Window] Cancel ___________________________________________________________________________ cc'ing Jatin to help with wording.

It sounds kinda strange to open new windows in response to Close Window, but I will admit to being weird, as you say: weird but *throrough*. ;-) Seems to me like cancel should always be allowed, and should cancel the operation, the dialog, and the pref setting. I'm not sure how the minimized case is so different from the principle you outlined, since in both cases they are closing open web pages they can't see.

My suggested wording: This Navigator window contains open Navigator tabs. Click "Close Window" to close the window, including all tabs within the window. To close only the web page being viewed, click the "X" button on the right side of the Tabbed Browsing bar, or press [Accel]+W. [ ] Do not warn again [Close Window] Cancel Notes: - Accel should be a variable for the platform-specific accelerator key. - In my online help, I've used the specific term "Navigator tab" and "Navigator window" to differentiate it from other windows and tabs (example: Sidebar tabs and Composer windows). After the initial reference to Navigator window or Navigator tab, simply referring to each as a window or tab is OK. - I've also decided to called the bar with tabs the "Tabbed Browsing bar" to be consistent with the related preference "Tabbed Browsing." - A tooltip needs to be added to the "X" button that closes the tab, reading, "Close this tab."

nsbeta1+/ADT3 RTM per Nav triage team ->1.0.1. Will consider dealing with this after we get beta feedback.

*** Bug 138732 has been marked as a duplicate of this bug. ***

*** Bug 140151 has been marked as a duplicate of this bug. ***

*** Bug 142789 has been marked as a duplicate of this bug. ***

I like Jatin Billimoria suggestion, but I think the following dialog may be even more effective: [ ] Remember My Preference [Close this Tab] Close this Window Cancel

You forgot about "Exit Mozilla", which is what the "big X" has done up until now. (Although I like the addition of "Close this Windows" while keeping other Mozilla sesssions alive.)

Actually, closing Mozilla should not be controlled by the X and currently isn't. Mozilla should close (unless Quick Launch is being used) when its last window is closed. Exiting Moz completely can be done by selecting Exit (instead of Close) from the File menu.

I'm talking about the Windows builds of Mozilla - I'm not sure what you're using. There are three icons, "Minimize," "Restore Window," and "Exit". Clicking on the "big X" (as opposed to the "tab X") does indeed exit Mozilla and it always has. This is standard Windows behaviour and anything else would be abberant. Also note that this bug *ALSO* covers the use of File / Exit. Hence, if you do this, the window that pops up should offer the choice of exiting completely (closing all tabs and windows) in addition to the other choices given in comment 52.

Quote: >Clicking on the "big X" (as opposed to the "tab X") does indeed exit Mozilla >and it always has. Well, it doesn't on my Win32 Mozilla (v1.0RC1-2002042708) I am sure you can verify this yourself: 1. Open 2 Mozilla windows, each with 2 tabs or more. 2. Press the "big X" on one window (any). Result: one window will close, but the other one/s will stay open -> Mozilla did NOT exit.

Sorry, my mistake. I must not be getting enough sun or something. Yes, it closes just the current window, not all windows.

removing plus for retriage

nsbeta1- per Nav triage team

*** Bug 145716 has been marked as a duplicate of this bug. ***

*** Bug 147404 has been marked as a duplicate of this bug. ***

#147404 is NOT a duplicate of this bug. Who ever labeled it as a duplicate obviously did not read it first. #147404 is a request for a feature that CAN be used as a work-around for this bug (#108973). It however has other uses - as would be noticed by anyone who actually read #147404.

*** Bug 148694 has been marked as a duplicate of this bug. ***

*** Bug 148861 has been marked as a duplicate of this bug. ***

In the original post the author mentions javascript window.close(). I believe this is a SEVERE problem with mozilla as often websites use javascript to control little help windows off the main page. After you are done reading such a help window that was opened in a new tab and click the javascript "close" link provided in the window, mozilla closes the whole browser!! This is AWEFUL, and I got bit by this bug for about the 5th time today while trying to check out on amazon.com. I had to restart my entire transaction. VERY irritating bug, I hope it gets fixed ASAP. I'm using mozilla 1.0 release on Linux.

Scott, that is a separate bug. And it has already been fixed.

[IMHO] If people would like safety nets, I say give them the option. But, since some UI people appear to against having an alert before accidentally closing for the whole browser (See bug 39057) it is not clear to me that an alert for just a window is going to be approved by those same guardians of UI purity. I recommend that further debate be taken to an appropriate newsgroup. No need to bother the developer (jag) with this discussion until agreement on the UI is reached.

I would see this as a toggle in the Tabbed Browsing preferences. No need to force the option on anyone.

Re: Comment #67: "I recommend that further debate be taken to an appropriate newsgroup." Why ? Of all of the many things in Mozilla that need fixing, this is by far one of the blatantly obvious bugs, as well as being one of the most serious bugs. Mozilla will _never_ be ready for prime time until this is fixed. Get it fixed NOW with a simple dialog box with "yes" and "no" options - worry later about refining the options and nitpicking over the wording. Crank out a basic no-frills fix, close this bug, then let the nitpickers open a new bug so they can fuss over the wording, etc., until hell freezes over. Rob

+1 vote for "Confirm on quit if more than one tab is open" feature (also a.k.a. "Multi-tabbed windows should confirm close").

70 comments worth of bickering (not all of them bickering) and not a patch in sight. There are a number of problems with the patch I'm about to post which are listed in this file, and which I'll reproduce in the comment on my next attachment.

(This patch is against CVS trunk from a day or two ago) Problems with this patch: It's a simple confirm dialog ("Ok" and "Cancel" buttons)--UI people hate this It is not localized/translated It offers no way to turn off future warnings (it could be done, though) Reasons why I'm adding it anyway: In all of 70+ comments, nobody has offered anything resembling a patch It's insanely simple (all javascript, one line of XUL) It saves people from losing lots of tabs while the bickering continues (see comment 69)

Another thing that someone starting from my patch should consider: according to an assertion that keeps rearing its head, navigator.js should be using the prompter service instead of window.confirm. I used window.confirm because I'm lazy and because it got the job done without me having to spend more than 20 minutes on it. :-)

Re: Comments #70 #71 #72 Thanks a million Tim ! And cut out the self-deprecating **** - you got the job done when everyone else either couldn't or wouldn't.

*** Bug 157720 has been marked as a duplicate of this bug. ***

*** Bug 157957 has been marked as a duplicate of this bug. ***

WOW this patch is brilliant (finally got a sec to apply it). i've no reason to upgrade or try "new" versions of the browser until a fix for this is incorporated--this bug is the only reason i'd upgrade this browser. any new status on an "official" patch?

*** Bug 161165 has been marked as a duplicate of this bug. ***

*** Bug 162093 has been marked as a duplicate of this bug. ***

untested code (sorry, dunno how to make a diff file.)

*** Bug 163094 has been marked as a duplicate of this bug. ***

*** Bug 164213 has been marked as a duplicate of this bug. ***

164213 Is not exactly a dupe, folks, since i would rather have seen a "lock this tab" button or something similar than a "confirm" dialog. I hate confirmation dialogs. However, i can live with it.

This bug is in the same category, so if everyone like the idea of a lock on it then it can be done. Anyone here like the idea of the lock in addition to this? Spill out your gut feeling and tell us what's on your mind.

Although the two are somewhat related, I think they're pretty different bugs... I would think of a confirmation to protect me from my ignorance... a "lock" as another feature, although I'm kind of confused as to how it might work. Each tab has a "lock" icon you lock your tab, and then when you click the "x" in the window decoration all tabs but the locked ones disappear? I don't even think that's possible on some window managers/OS's You could use the "lock" to prompt a dialogue, but in that case, I think that just a dialogue box that you could turn off if you'd like would be sufficient and a lock icon would add more clutter to the interface.

Mozilla has - at least for me - become the most important tool. Since i work with it every day and all our tooling allows access via webbrowser the locking feature would be an important step to make it a kind of "work-environment". AFAIK there are issues about automatically opening several tabs at startup with predefined urls. Those two features in conjunction would save me lots of time. A feature that lets all tabs reload in specific intervals would add to it (i know there's another issue for this). To put it simple: Mozilla is the most perfect tool i've ever used. These small addition would give it an extra edge.

The more i think over it: It could find a place in the tab's context menu. There could be a conditional cascade "Tab Options" with items like "Lock", "Reload Every...", "Reload URL At Startup" ...

I still don't understand exactly what feature you're looking for. I'm sorry if I'm missing something. Could you provide a very exact description of how this would work?

The more i think over it: It could find a place in the tab's context menu. There could be a conditional cascade "Tab Options" with items like "Lock", "Reload Every...", "Reload URL At Startup" ...

Sorry for the double posting ... Nick, i want an option to prevent specific tabs from being closed. There are some webpages i want to remain open all the time and if i do a "close other tabs" i want those tabs to be ignored by the command. The background is that i use a webbased bugtracking system. I have an intray that i want to remain open all day long, going back to that intray takes some time (logging in etc.). Every action in this bugtracker opens other windows - or after i changed some settings - they open in new tabs. Those tabs might be closed after i'm done with them. In the mean time i'm browsing in other tabs, looking for additional information i want for my bugwriting (references and followups to other issues etc.) and sometimes i browse to some pages like slashdot.org or osnews.com (private browsing that is ...). During this i end up with a large number of tabs, some of them provide information i need and want to continue working with. So i want to lock them. The difference to "Close other tabs" is that i can end up with a couple of tabs i marked and i protect myself against closing tabs i need by accident.

Makes sense... I think that is a completely different bug. You're working with "close all other tabs," whereas this bug would protect against closing the entire window... Does anyone agree?

I agree. This bug is only about guarding against the accidental closure of the entire window. Plus it's specifically about popping up a confirmation dialogue - not putting a setting on a tab.

Close Other Tabs is being removed (see bug 103354).

FYI, someone change this bug #164213 from duplicate to unconfirm. Thank you all for your feedback. I'm now setting that bug #164213 from unconfirm to new. I think this bug #164213 will make a find addition to Mozilla.

I've been discussing this in the wishlist group, and would like to add some comments. Firstly, my original observation was that it is too easy to press Ctrl+Q (close everything) instead of Ctrl+W (close tab), as the keys are right next to each other: I did this by mistake with over 40 tabs open and was not happy :-( I say that there should definitely be a prompt when a user attempts to close the browser, by any means, if by doing so it will close windows or tabs that are not currently visible to the user. This has been compared (correctly) to the unsaved documents prompt in most applications. It has also been suggested that this is an incorrect analogy, because any work can be easily recovered. However, if you have 100 tabs open simultaneously, tracking them all down again is not an insignificant task. Also, it is incorrect to assume that there cannot be any true "unsaved" data. Web pages can in fact contain unsaved user data. A simple example is a form that has not yet been posted, especially webmail. A more complex example would be user-dependant DHTML content. These represent unsaved data that may exist in a hidden tab, or even the current one. I say that there is no point in checking these cases, and all hidden pages should be considered "unsaved". I think it's still fair to assume that if there is only one window/tab open, then the user really does mean to exit. However, if there is more than one window or tab then it should be that the close request is ambiguous. The prompting mechanism can be quite simple, and need not encumber users that really do wish to quit everything. Simply display a prompt with the following options (prehaps using radio buttons and an OK/cancel dialog, like Windows 9x shutdown): You are trying to exit Mozilla. Is it really your intention to: - Close all instances of Mozilla (default) - Close the current Mozilla browser window (not displayed if there is only one tabbed window open) - Close the current tab (not displayed if the current window is not tabbed, but there is at least one other window open) One extra confirm click (or press enter) to exit Mozilla is not a great labour for people that really do want to exit. However, for other users it could potentially save a lot of wasted valuable time. Additionally, a default option could be placed in the preferences somewhere, for brave users that wish to disable this prompt. However, I would not recommend placing a "do not ask me this again" checkbox on the dialog, as many new users may check it without realising the possible ramifications. That would partly undermine the usefulness of the feature. - Robert

CC:ing self

*** Bug 170406 has been marked as a duplicate of this bug. ***

Moving to 1.0.2 since it missed 1.0.1 and nominating for nsbeta1. Mat the bug owner also change the target milestone?

I'm a regular user of Mozilla and have some wood to throw on the fire: First, what I really want: Mozilla to warn me when I am about to close a tab or window containing unposted form entries. I'm still reeling from a big loss (2 hour bug report - should've used a text editor) several weeks ago. I'm gonna apply the patch from #80, and hope that at least warnings about unsaved form data make it into a not-too-distant release. I don't have any new suggestions, but thought it might be helpful to summarize what seems to me to be the root cause of this discussion, namely the types of state that are being lost when a Mozilla window is closed: 1. unsaved, user entered data (like forms) 2. the list of currently tabbed URL's. 3. URL content (web pages) that can only be viewed once. #164213 seems to deal with this issue. Maybe I'm stating the obvious, but it seems like you need a way (perhaps many) to deal with all three.

I have run into this myself and have lost data I was entering in to bugzilla. I love tabbed browsing except when I xclose accidently, from the title bar, a window I brought up temporarily. If we had a preference for warning me when I'm about to close all tabbed windows I would use it until my habit of xclose from title bar is no longer a problem.

*** Bug 173576 has been marked as a duplicate of this bug. ***

*** Bug 179410 has been marked as a duplicate of this bug. ***

Umm, after being first brought up over a year ago I'm amazed that this still isn't fixed... This is a feature request rather than a bug. I open a lot of windows while browsing. Now I use Mozilla I open a lot of tabs. If I accidentlly close the window, all of the tabs are gone without confirmation. Feature Request 1: If a browse window has more than one open tab in it, on closing the window give the user a "do you really want to close all tabs?" dialogue box. Feature Request 2: For users who would not want to be bothered with this message, provide an option in the browser preferences "warn when closing multi-tabbed window". Reproducible: Always Steps to Reproduce: 1. Open several tabs while browsing. 2. Click on X to close the window. 3. Note that all open tabs were closed in one easy move. Actual Results: Panic because you didn't note any of the URLs and will never find the stuff again :-) Expected Results: For each window that contains more than one open tab, ask the user for confirmation, before allowing window to be closed. Have a setting in preferences that can override this option, as some users will not want this feature.

What about a small mark such as a check box on each tab that the user could enable - each tab with this mark would give a confirmation before close when the main [X] was clicked - closing the tab normally would be as-is.

Regarding a small checkbox on each tab... I think that's way too complicated. This issue is mind-boggling... I can't believe this is more than a year old. It is so incredibly simple. All there needs to be is a preference that says "Warn when closing a window with multiple open tabs." Done! That's all! Why hasn't this been added?

I agree. The powers that be need to decide whether this is going to be fixed or dropped.

Would this be a complicated feature to add? I'm wondering if I could do this myself, seeing as how there's been no progress on this issue.

Re: comment #107 Yes, you can do this yourself. It *is* trivial to fix this and a fix has been available for a *long* time - since July 4 as a matter of fact. Go back to the top of this bug page and look at the table for the attachments. The first one is a readme file and the second one is the corresponding patch. It works *wonderfully*. It is truly amazing that it has not been made a permanent part of Mozilla.

>> It *is* trivial to fix this and a fix has been available for a *long* time - since July 4 as a matter of fact. << How can this fix be applied to the copy of Mozilla 1.1 [20020826] that I use on Windows 98se? It is about the only thing in Mozilla that I really want fixed.

Nav triage team: nsbeta1-

*** Bug 187073 has been marked as a duplicate of this bug. ***

Just wondering what the plan is for this bug. I noticed that konqueror people have implemented in the first release of their tabbed browser. Is this going to be quietly ignored forever?

*** Bug 195236 has been marked as a duplicate of this bug. ***

Just to help you make your mind: my girl friend is mainly a Mozilla user. When she tried Konqueror 3.1 for the first time, she noticed the "do you really want to close this window" message when you have mutliple tabs. Her reaction was a "I want the same thing in Mozilla ! That's so useful to avoid losing all your work !" reaction. The thing is that some people really use Mozilla to edit _documents_. For example, my GF works in real estate and she uses Mozilla mainly to edit properties' descriptions. For her, closing a tab by error is like closing a document without saving it. So I vote for this in Mozilla !

One more case where this bug causes problems: W is right next to Q on QWERTY keyboards, and I have sometimes hit ^Q instead of ^W, losing all my tabs. Tim's patch works great though.

Chris, what you are describing is Bug 52821 - "too easy to hit CTRL+Q instead of CTRL+W". A critical dataloss bug with 43 votes, almost 200 comments, countless dupes, *a working patch* and no end in sight. Prog.

I just did it again. Two hours of reading, selecting and marking is gone, because I accidently Xed the wrong window. I really would like to see this fixed soon. Everthing else is said in Comment #95

Well, since it seems that no one has even bothered to look at this bug, who do we need to bother to get this fixed?

*** Bug 201628 has been marked as a duplicate of this bug. ***

Okay, this is silly. There are 70(!) votes for this bug, 119 comments and a WORKING patch, yet for some reason no one has implemented this into the Mozilla trunk. Why?!

Could it be because jag is busy with other bugs with even worse consequences?

I think that this is a more critical bug that it appears to be at first glance. I have switched many of my friends to Mozilla from IE, and this issue is probably the top complaint. If there are more severe bugs in other places, they aren't apparent to the end users and as such are (in my uninformed opinion) less critical to the improvement of Mozilla.

This bug is already fixed - see homepage of Tabbrowser Extensions: http://white.sakura.ne.jp/~piro/xul/_tabextensions.html.en these extensions add lot of useful functions to mozilla: - Auto Reload (Reloads tabs with favorites interval) - You can open last visited tabs instead of last visited page when Navigator starts up (also browsing history is saved !!!) - Also this can restore tabs at the next startup of crash - Tabbrowser Extensions autosaves URL of open web pages !!! (browsing history is saved too !!!) - this closes bug #36810 - You can undo "Close Tab" until fifty times ago - You can re-open the closed tab by Ctrl+Shift+Z or Alt+Z - Tabs are moved and re-ordered with drag and drop. - zillion of other improvements. Mozilla developers, please include this wonderfull utility into Mozilla.

Ah! Excellent. I didn't try the other features - but for confirm close, it's perfect!

I firmly disagree with comment #123- half of the RFEs and feature bugs in Mozilla can be solved by installing XPIs. *However*, installing all of these addons creates massive, unmitigated bloat and contributes to slowdowns. Furthermore, I call your attention to the following: http://white.sakura.ne.jp/~piro/xul/_img/tab_context.jpg The menu is gigantic beyond belief, and the feature overload is unbelievable. Features are nice, yes, but the superfluous and downright silly features should never be included in a workable human interface. That menu is in direct contravention of the Macintosh, IBM, KDE, heck, even *Microsoft* human interface guidelines. While certainly not amateurish, the extension's user interface does not conform to the standard of professionalism we've come to expect from Mozilla. The solution to this bug should be simple for those with privileges and/or coding knowledge: check the patch or a new one- with maybe 50 lines of code, tops- into the trunk that confirms the close. Neither Tabzilla nor #123's extension solve the problem satisfactorily.

Dirty, yes. I agree. This patch shouldn't be merged. It works just fine as it is... *However* after one and a half years, I'm very happy to have a very simple to install confirm close dialog.

> I firmly disagree with comment #123- half of the RFEs and feature bugs in > Mozilla can be solved by installing XPIs. *However*, installing all of these > addons creates massive, unmitigated bloat and contributes to slowdowns. 181kB large jar (tabextensions.jar) doesn't make mozilla any more "bloated" than it is, if it is at all, but brings many high priority features to me *without* sacrificing performance (PIII 1GHz). > http://white.sakura.ne.jp/~piro/xul/_img/tab_context.jpg > The menu is gigantic beyond belief, and the feature overload is > unbelievable. The menu is gigantic like any other mozilla menu, nothing unusuall. I won't comment feature overload cause I like new features and can't get enough of them. I know it's hard to adopt to mozilla going from an early lynx versions. :) I firmly believe that *at least "warning window"* should be *added* as an option to tabbed browser preference in latest mozilla brench now and *keep* it there forever. :) > The solution to this bug should be simple for those with privileges and/or > coding knowledge: check the patch or a new one- with maybe 50 lines of > code, tops- into the trunk that confirms the close. Neither Tabzilla nor > #123's extension solve the problem satisfactorily. But your patch/compilation process each time you want to upgrade mozilla is simple and satisfactory? Don't make me laugh. Anyway, that XPI is great and it works for me, kudos for the developers, hopefully mozilla bosses will in the end integrate something from it into mozilla or Firebird. regards

I dont think this should be a rfe, when i used tabbed browsing i read whats in a tab and then i shut it, so when i've finished with a browser window i wouldn't have any tabs open. I think its safe to assume if tabs are open then they are still in use and shouldn't be lost. Severity -> Critical?

I'm going to mark all the previous patches as obsolete. The initial patch works for me, but it's not clean enough, because the UI string must be put into localizable string bundle. Sorry, the second patch about confirming when there are form contents, does not work for me. I think confirming unsaved forms should be a separate bug anyway.

I think this patch is clean and it works for me.

Opened: 2001-11-07 16:02 2003-04-19: Stop faffing around and just fix the damn bug. This is beyond a joke now.

> Stop faffing around and just fix the damn bug. This is beyond a > joke now. Ian, g1smd@freeuk.com, may I ask you to be a bit more friendly? This is not a system for complaints, but for tracking technical details and status. I wonder how you can ask for work being done, complaining, but not contributing anything on your own. You might not have noticed, but today I invested personal free weekend time to work on an updated patch that follows the rules of the Mozilla project. By being rude, you don't motivate people to contribute free time on their own. Why should I do that again, if all I hear back are complaints? Your words make me feel very sad. A lot of people are caring to make sure this project is in the open. But time and resources are always limited. You don't reach anything positive by being rude. sigh

Kai Engbert: I've had a brief look at your patch (I haven't looked at the previous patches, admittedly), and from a Usability perspective, it appears to have a major flaw: The warning dialog says "This window has %S navigator tabs open. Please confirm you want to close the window and all its open tabs." and thus makes it unclear what the available buttons (I presume they're "OK" and "Cancel" from the javascript function used). May I suggest using a different javascript function instead, and replacing "OK" with "Close All Tabs" ("Cancel" can be left as is)? That said, might I point everyone complaining about the age of this bug to this nice little page: http://bugzilla.mozilla.org/page.cgi?id=etiquette.html . Thanks for reading it.

> May I suggest using a different javascript function > instead, and replacing "OK" with "Close All Tabs" ("Cancel" can be left as is)? Makes sense. New patch attached.

Is there any chance that this patch could be tied into a back-end pref (say "browser.tabs.closeWarning") with a default value of True? That way, anybody who doesn't want to see the warning can change it to False. (I don't want to see a "Remember this" or "Don't ask me again" option causing a messy UI, but there should be some way for "power" users to disable this if they choose.)

Oh, and w/r/t comment 131 - just ignore such things. You're doing a great job coming up with a patch and I, for one, greatly appreciate it.

Does this patch work on Linux, Windows and Mac?

On Mac, it successfully blocks the close button, but doesn't work for command-shift-w or command-q.

*** Bug 205882 has been marked as a duplicate of this bug. ***

Patch v4 currently applies with some fuzzing and offset; this is the same patch applied and re-diffed against latest CVS. Also, it takes advantage of the undocumented tryToClose property to catch Quit in addition to normal closing.

Comment on attachment 124927 [details] [diff] [review] Patch v5 Carrying over kaie's review request. I can confirm it works on linux.

/me wonders why /xpfe/global/resources/content/bindings/tabbrowser.xml doesn't have a routine for counting real tabs (e.g. has URL or sessionHistory)

Comment on attachment 124927 [details] [diff] [review] Patch v5 >Index: xpfe/browser/resources/content/navigator.js >=================================================================== >RCS file: /cvsroot/mozilla/xpfe/browser/resources/content/navigator.js,v >retrieving revision 1.506 >diff -u -r1.506 navigator.js >--- xpfe/browser/resources/content/navigator.js 2 Jun 2003 14:31:48 -0000 1.506 >+++ xpfe/browser/resources/content/navigator.js 4 Jun 2003 18:47:32 -0000 >@@ -2262,3 +2262,26 @@ > } > return null; > } >+ >+function WindowIsClosing() { The { should be on its own line (see rest of the file). >+ var browser = getBrowser(); >+ if (browser && browser.localName == 'tabbrowser') { No need for this check, |browser| will always be non-null, and a tabbrowser (if someone wishes to edit navigator.xul in their version, they can update/remove these functions themselves). >+ var numtabs = browser.mTabContainer.childNodes.length; >+ if (numtabs > 1) { >+ var promptService = Components.classes["@mozilla.org/embedcomp/prompt-service;1"]. >+ getService(Components.interfaces.nsIPromptService); >+ if (promptService) { >+ var checkValue = {value:false}; >+ var buttonPressed = promptService.confirmEx(window, >+ gNavigatorBundle.getString('tabs.closeWarningTitle'), >+ gNavigatorBundle.getFormattedString("tabs.closeWarning", [numtabs]), >+ (promptService.BUTTON_TITLE_IS_STRING * promptService.BUTTON_POS_0) + >+ (promptService.BUTTON_TITLE_CANCEL * promptService.BUTTON_POS_1), >+ gNavigatorBundle.getString('tabs.closeButton'), >+ null, null, null, checkValue); Either make the checkValue parameter be null (so you don't get a checkbox) or store its .value in a pref so you can skip asking the question next time around. >+ return (0 == buttonPressed); I'd prefer |return (buttonPressed == 0)| for readability. ... >+} window.tryToClose = WindowIsClosing; Add the above and you can undo the change in navigator.xul

"Either make the checkValue parameter be null (so you don't get a checkbox) or store its .value in a pref so you can skip asking the question next time around." Nevermind that comment. You only get a checkbox if you provide a string for it. Still, it'd be nice to be able to say "I don't want to be asked again" for this dialog. Also, you'll still need the |onclose| change to navigator.xul, of course.

> Still, it'd be nice to be able to say "I don't want to be asked again" for > this dialog. As I mentioned in comment 135, I'd like to just see a hidden pref to disable the confirmation, and not a dialogue checkbox. Using such a checkbox brings up other problems. Not only does it complicate the UI, but it also raises the question of how to "re-enable" the confirmation if you click it by mistake. (For regular users that is, power users would know that having checked it there must be a pref in place somewhere that can be changed back.) If there's going to be a checkbox anywhere, it should be in the Tabbed Browsing pref panel (where it's exposed and easily accessible in terms of turning it on and off at will) not in the confirmation dialogue.

This one fixes the listed problems and adds the ability to disable the prompt. Currently, there is no way besides manually editing the preferences to turn it back on once it is turned off. The pref is browser.tabs.warnOnClose. I did this to be consistent with the current UI. If there is enough desire, it can be additionally exposed in the preferences panel, but I won't go near that UI with a 10 foot pole. Feel free to add a pref-panel-modifying patch yourself if you wish to have it. There are a couple of unrelated cleanups of navigator.js at jag's behest.

Shouldn't we store the pref value regardless of which button the user pressed?

Hmm, I guess the "Cancel" would suggest to the user that the don't ask would not be remembered. Which makes sense, because the user actually wanted to abort the quit/close action, and was probably happy (s)he got asked.

If you don't have any other serious concerns, can I put this on branch radar? Or is that out of the question at this point? (I ask because about:config is a relatively hidden feature, so it's very low-risk.) Or is that what "ADT 3 RTM" does?

Comment on attachment 125022 [details] [diff] [review] Patch v6 please don't request approval to land changes onto the 1.4 branch until you've got sufficient reviews. thanks.

*** Bug 208993 has been marked as a duplicate of this bug. ***

Comment on attachment 125022 [details] [diff] [review] Patch v6 >Index: mozilla/xpfe/browser/resources/content/navigator.js >=================================================================== >RCS file: /cvsroot/mozilla/xpfe/browser/resources/content/navigator.js,v >retrieving revision 1.506 >diff -u -p -r1.506 navigator.js >--- mozilla/xpfe/browser/resources/content/navigator.js 2 Jun 2003 14:31:48 -0000 1.506 >+++ mozilla/xpfe/browser/resources/content/navigator.js 5 Jun 2003 20:07:43 -0000 >@@ -2261,4 +2263,40 @@ function maybeInitPopupContext() > } catch(e) { > } > return null; >+} >+ >+function WindowIsClosing() >+{ >+ var browser = getBrowser(); >+ var numtabs = browser.mTabContainer.childNodes.length; >+ var reallyClose = true; >+ >+ if (numtabs > 1) { >+ var shouldPrompt = pref.getBoolPref("browser.tabs.warnOnClose"); >+ if( !shouldPrompt ) { Extra spaces >+ return true; >+ } >+ >+ var promptService = Components.classes["@mozilla.org/embedcomp/prompt-service;1"]. >+ getService(Components.interfaces.nsIPromptService); Typically the style for this is (space permitting): var promptService = Components.classes["@mozilla.org/embedcomp/prompt-service;1"] .getService(Components.interfaces.nsIPromptService); >+ if (promptService) { >+ //default to true: if it were false, we wouldn't get this far >+ var warnOnClose = {value:true}; >+ >+ var buttonPressed = promptService.confirmEx(window, >+ gNavigatorBundle.getString('tabs.closeWarningTitle'), >+ gNavigatorBundle.getFormattedString("tabs.closeWarning", [numtabs]), >+ (promptService.BUTTON_TITLE_IS_STRING * promptService.BUTTON_POS_0) >+ + (promptService.BUTTON_TITLE_CANCEL * promptService.BUTTON_POS_1), >+ gNavigatorBundle.getString('tabs.closeButton'), >+ null, null, >+ gNavigatorBundle.getString('tabs.closeWarningPromptMe'), >+ warnOnClose); >+ reallyClose = (buttonPressed == 0); >+ if (reallyClose) { if (reallyClose && !warnOnClose.value) No need to store the pref if it's gonna be true, since we know it is true before the call below. >+ pref.setBoolPref("browser.tabs.warnOnClose", warnOnClose.value); >+ } >+ } >+ } >+ return reallyClose; > } r=jag with those changes

Changes made.

Comment on attachment 125544 [details] [diff] [review] Patch v7 >+ window.tryToClose = WindowIsClosing; Bah, why doesn't globalOverlay.js send a close event? I guess we're stuck with this hack for now. >+ if (numtabs > 1) { >+ var shouldPrompt = pref.getBoolPref("browser.tabs.warnOnClose"); >+ if (!shouldPrompt) { >+ return true; >+ } [... return reallyClose] This is just plain ugly. Either consistently early return, or nest your ifs. >+ var promptService = >+Components.classes["@mozilla.org/embedcomp/prompt-service;1"] >+.getService(Components.interfaces.nsIPromptService); Since this is appeared to wrap for jag, I think he was trying to say to line up the dots: var stuff = Components.classes["@mozilla.org/stuff;1"] .getService(/*more stuff*/); >+ if (promptService) { Note that promptService is always set at this point, any previous failure would have resulted in a thrown JS exception - jag, do you want a try/catch here instead? >+ if (reallyClose && !warnOnClose.value) { Interestingly the SSL dialogs always set the pref, even after cancelling :-) >+ pref.setBoolPref("browser.tabs.warnOnClose", warnOnClose.value); We know warnOnClose.value is false by now :-) I think I've picked enough nits for an r- ;-)

> This is just plain ugly. Either consistently early return, or nest your ifs. done. >+ var promptService = > >+Components.classes["@mozilla.org/embedcomp/prompt-service;1"] > >+.getService(Components.interfaces.nsIPromptService); > blah blah line up dots done. > Note that promptService is always set at this point, any previous failure > would have resulted in a thrown JS exception - jag, do you want a try/catch > here instead? done. > Interestingly the SSL dialogs always set the pref, even after cancelling :-) intentionally not done. =) > >+ pref.setBoolPref("browser.tabs.warnOnClose", warnOnClose.value); > We know warnOnClose.value is false by now :-) fixed.

Comment on attachment 125981 [details] [diff] [review] patch v8 >>+ if (promptService) { >Note that promptService is always set at this point, any previous failure would >have resulted in a thrown JS exception - jag, do you want a try/catch here >instead? try/catch shouldn't be needed, getting the prompt service won't fail. sr=jag with that removed (sorry for not responding sooner).

What jag said.

Fix checked in.

Marking fixed (forgot to in the last comment; sorry folks)

Excellent! However, it's ignoring File -> Close Window (and Ctrl-Shift-W). (Every other method of closing the window / exiting the browser seems to trigger the dialogue, but not this one.) I've filed bug 210639 for this specific case.

If I understand correctly, this has landed on the trunk, but is not contained in versions 1.4 or earlier. For what it's worth, stability enhanced Linux, Mac OSX and Windows builds based on Mozilla 1.3.1, that also contain the patch from this bug, are available at http://wamcom.org The patch contained in the build is patch v4.

Just a comment: Shouldn't we be able to close multi-tabbed window without any warning, if that window contains empty tabs only?

v

Re comment 162: file an RFE, please, if you want that.

I don't understand why this bug is related to tabs. I'd expect a simple dialog "Really exit Mozilla?" if the the last or only mozilla window is closed. And in the settings, I can check "_ confirm on exit" if I want that confirmation.

> I don't understand why this bug is related to tabs. Because that's what this bug was specifically filed about (re-read the summary, description, and comments). If you want something else, then file a different bug. Note that this bug is verified fixed.

This change was implemented in order to get around the very real annoyance of unintended closing of the browser window when there are multiple tabs opened. A similar situation existed in certain other software products and these products confirm before closing the application to avoid this situation. However, this implementation, unlike the implementation of similar features in other products, has undesirable consequences. This implementation presents the "user" with a dialog box when the browser is shut down. This happens regardless of what triggered the shutdown of the browser. This includes cases where the user takes actions such as clicking Ctrl-Q or File > Exit, or when Windows is shutting down. It is in the latter case where this implementation differs from how other products handle this situation. In cases where the operating system is shutting down, no assumption exists that the user expects other browser windows to remain open or that shutting down additional tabs may be unintentional. Users who shut down Windows do not always remain at their computers to see if dialog boxes appear since they are not normally expected. This introduces a dialog box that prevents the normal shutdown of the operating system. Unlike other cases where applications may cause this, this behavior is introduced as part of the normal operation of the browser rather than as the result of an extraordiary event. This implementation of the dialog box is a feature that is activated by default and may not be expected by a user who shuts down his computer. Users who routinely shut down their computers without first closing Mozilla will no longer be able to do so when multiple tabs are open. This also introduces a security issue for some users whose computers will remain active after they expected that the computer was being shut down. Turning off this feature serves as a work around, but negates its beneficial purpose. This issue should be readdressed so that the dialog box appears whenever a user shuts down a browser window with mutiple active tabs, but not when Windows is shutting down. Until such time, it is not a desirable default behavior.

I don't know if I agree with that. I just did a session->quit on konsole and a location->quit on konqueror and they both still prompted me... Although your shutting down example wouldn't affect me due to the way Linux handles shutdowns different than windows. Anyway... I would consider the tab confirmation box similar to closing a ms word document without saving. You will get prompted, and windows will freeze up. I don't know if I see a difference between clicking the "x" in the upper righthand corner and hitting ctrl+q. Maybe a separate bug could be filed to allow you to fine tune this feature more? just a thought...

The difference is that when a person has a document with unsaved changes and is shutting down the operating system, that constitutes an extraordinary event. The presumption is that the person made the changes for a reason and there is a reasonable expectation that the person may want to save the work. This differs from having windows opened when a user is merely browsing web pages. The presumption is not there. I agree that if it were carried to that level, a browser window with unsubmitted form data might be analagous. However, that situation is not germane. In a case with even a single tab it might be a legitimate concern if a form has unsubmitted data, but that would be a different feature from the one in question. The purpose here is to alert the user that there are other tabs opened and to prevent the user from closing them inadvertantly when it was the user's intention to keep working. If a user is shutting down a computer that there is no intent to keep working and closing of other tabs in not presumed to be inadvertant. Another way to look at this would be with a truth table. If the user gets the prompt, either he intended to close the individual tab or he intended to close the browser. No matter which assumption we made in the case of Mozilla, Windows would subsequently shut down anyway. If we made either assumption arbitrarily for the user, the result would be the same. Therefore, no logical purpose is served. In the case of an unsaved Word document, making the assumption arbitrarly to save or discard would not result in logically equivalent outcomes. While on the surface, Word's shutdown situation seemed analagous, it is not. An analagous product would be a web browser. (Opera, for example, prompts to prevent accidental shutdown of the application but I believe does not do so when Windows is shutting down.) That's why I wouldn't consider a prompt for an unsaved Word document at shutdown time to be unexpected behavior. However as a user, I did not expect it from Mozilla. It was after another user found her computer still running the next morning that it became clear that she did not expect it either. While the Word prompt might be a saving grace, this one seems to need some fine tuning.

Well, I still disagree. If you are shutting down your computer with a bunch of windows still open, you are asking for these kind of dialogue boxes. Seeing that the other tabs are more or less hidden, you could still be closing windows accidentally whether you do it by closing the window and then shutting down windows or just closing windows... I think that if one does not wish to be prompted, they should still just disable the dialogue. If they wish to be prompted, then they wish to be prompted whether they are closing one window Ctrl+Shift+W or closing all windows Ctrl+Q. I still think that the best course of action is to open a new bug for fine tuning the confirmation... a timeout or options for different closing methods would probably be easy to add, but probably deserve their own bug.

> Seeing > that the other tabs are more or less hidden, you could still be closing windows > accidentally whether you do it by closing the window and then shutting down > windows or just closing windows... > Yes, but that has nothing to do with the nature of this change. You could have 15 browser windows open with a single tab each and still make your claim. The others or all are more or less hidden. In that case, this would have nothing to do with tabs. But the issue does have to do with tabs and the fact that somebody wants to close a single tab but expects the others to remain open. I'm talking about a case where somebody does not expect anything to remain open. You are talking about a case where somebody might have forgotten that he is working on something rather than a case where he meant to close a single tab and wanted to avoid closing others by mistake. It's not the same thing. A prompt before closing the browser under any circumstances would address your issue, but again, that's not related to the tab issue per se. That would have to be done irrespective of tabs or you would not accomplish your goal. It simply addresses a different issue, and that could be a different request. Perhaps you'd like to see an optional prompt before closing any browser window as with Opera. I agree it might be nice for some and would do exactly what you want. But it would not help those whose goal it was to solve the original problem and should be dealt with as a separate issue.

"This differs from having windows opened when a user is merely browsing web pages. The presumption is not there. I agree that if it were carried to that level, a browser window with unsubmitted form data might be analagous." Good point, which is expressed more fully in bug 48333. How about the following default behavior? 1. Always prompt before closing a window that contains an <input type="text"> or <textarea> element that has been modified, even if the window has only one tab. Here, user expectations are in line with "Save changes?" alerts in other applications. 2. Prompt before closing a window with multiple tabs in response to Ctrl+Shift+W, Ctrl+Q, or a close request from the window manager generated by a click of the window's close box. 3. On those systems whose window managers let them distinguish a close box click from a user logout, do not prompt in response to a shutdown event unless rule 1 applies.

*** Bug 225509 has been marked as a duplicate of this bug. ***

*** Bug 263886 has been marked as a duplicate of this bug. ***

Just got hit by this bug. It closed 4 or 5 tabs without asking. Please reopen. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050303 Firefox/1.0+ (bangbang023)

(In reply to comment #172) > How about the following default behavior? > > 1. Always prompt before closing a window that contains an <input type="text"> > or <textarea> element that has been modified, even if the window has only > one tab. Here, user expectations are in line with "Save changes?" alerts > in other applications. > 2. Prompt before closing a window with multiple tabs in response to > Ctrl+Shift+W, Ctrl+Q, or a close request from the window manager generated > by a click of the window's close box. > 3. On those systems whose window managers let them distinguish a close box > click from a user logout, do not prompt in response to a shutdown event > unless rule 1 applies. I think that approach makes sense. Since the time of those discussions, I've had ample opportunity to get used to the idea of the X closing the whole browser, so I merely disabled the prompt. But for those who are first making the transition to tabbed browsing, I think the approach outlined would be helpful.