Closed Bug 108973 (tabclose) Opened 23 years ago Closed 21 years ago

Multi-tabbed windows should confirm close

Categories

(SeaMonkey :: Tabbed Browser, enhancement, P5)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: mozilla, Assigned: jag+mozilla)

References

Details

(Keywords: dataloss, Whiteboard: [ADT 3 RTM])

Attachments

(1 file, 9 obsolete files)

patch v9
(deleted), patch
Details | Diff | Splinter Review 
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.
Whiteboard: this is a duplicate; look for bug reports under Tabbed Browser first
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: this is a duplicate; look for bug reports under Tabbed Browser first
*** Bug 111021 has been marked as a duplicate of this bug. ***
This seems like a silly workaround.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
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.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
QA Contact: blaker → sairuh
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. ***
URL: any
*** 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.
Keywords: mozilla1.0.1, nsbeta1
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.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [ADT 3 RTM]
Target Milestone: mozilla1.1alpha → mozilla1.0.1
*** Bug 138732 has been marked as a duplicate of this bug. ***
*** Bug 140151 has been marked as a duplicate of this bug. ***
Priority: -- → P5
*** 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
Keywords: nsbeta1+ → nsbeta1
nsbeta1- per Nav triage team
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0.1 → mozilla1.1alpha
*** 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
Alias: tabclose
+1 vote for "Confirm on quit if more than one tab is open" feature (also a.k.a.
"Multi-tabbed windows should confirm close").
Attached file Readme for the patch I'm about to attach (obsolete) (deleted) — 
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?
Keywords: patch
*** Bug 161165 has been marked as a duplicate of this bug. ***
*** Bug 162093 has been marked as a duplicate of this bug. ***
Attached patch prompt for unsaved forms (obsolete) (deleted) — — Splinter Review 
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?
Keywords: mozilla1.0.1, nsbeta1- → mozilla1.0.2, nsbeta1
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.
QA Contact: sairuh → pmac
Summary: [RFE] Multi-tabbed windows should confirm close → Multi-tabbed windows should confirm close
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. ***
Keywords: mozilla1.2
Attachment #94805 - Attachment is patch: true
Keywords: dataloss, mozilla1.3, review
*** 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-
Keywords: nsbeta1 → nsbeta1-
*** Bug 187073 has been marked as a duplicate of this bug. ***
Flags: blocking1.3b?
Keywords: mozilla1.2, patch, review
Flags: blocking1.3b? → blocking1.3b-
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?
Blocks: majorbugs
Keywords: mozilla1.0.2
Flags: blocking1.4a?
Keywords: mozilla1.3
*** 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 !
Flags: blocking1.4a? → blocking1.4a-
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.
Flags: blocking1.4b?
Target Milestone: mozilla1.1alpha → ---
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.
Attached patch Patch v3 (obsolete) (deleted) — — Splinter Review 
I think this patch is clean and it works for me.
Attachment #90258 - Attachment is obsolete: true
Attachment #90260 - Attachment is obsolete: true
Attachment #94805 - Attachment is obsolete: true
 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.
Attached patch Patch v4 (obsolete) (deleted) — — Splinter Review 
> 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.
Attachment #121062 - Attachment is obsolete: true
Attachment #121092 - Flags: review?(jaggernaut)
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.
Flags: blocking1.4b? → blocking1.4b-
*** Bug 205882 has been marked as a duplicate of this bug. ***
Attached patch Patch v5 (obsolete) (deleted) — — Splinter Review 
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.
Attachment #121092 - Attachment is obsolete: true
Comment on attachment 124927 [details] [diff] [review]
Patch v5

Carrying over kaie's review request. I can confirm it works on linux.
Attachment #124927 - Flags: review?(jaggernaut)
/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
Attachment #124927 - Flags: review?(jaggernaut) → review-
"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.
Attached patch Patch v6 (obsolete) (deleted) — — Splinter Review 
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.
Attachment #124927 - Attachment is obsolete: true
Attachment #125022 - Flags: review?(jaggernaut)
Attachment #121092 - Flags: review?(jaggernaut)
Attachment #125022 - Flags: superreview?(blaker)
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?
Attachment #125022 - Flags: approval1.4?
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.
Attachment #125022 - Flags: approval1.4?
*** 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
Attachment #125022 - Flags: review?(jaggernaut) → review+
Attached patch Patch v7 (obsolete) (deleted) — — Splinter Review 
Changes made.
Attachment #125022 - Attachment is obsolete: true
Attachment #125544 - Flags: superreview+
Attachment #125544 - Flags: review?(neil.parkwaycc.co.uk)
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- ;-)
Attachment #125544 - Flags: review?(neil.parkwaycc.co.uk) → review-
Attached patch patch v8 (obsolete) (deleted) — — Splinter Review 
> 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.
Attachment #125544 - Attachment is obsolete: true
Attachment #125981 - Flags: superreview?(jaggernaut)
Attachment #125981 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #125022 - Flags: superreview?(blaker)
Attachment #125981 - Flags: review?(neil.parkwaycc.co.uk) → review+
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).
Attachment #125981 - Flags: superreview?(jaggernaut) → superreview+
Attached patch patch v9 (deleted) — — Splinter Review 
What jag said.
Attachment #125981 - Attachment is obsolete: true
Fix checked in.
Marking fixed (forgot to in the last comment; sorry folks)
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
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.
No longer blocks: majorbugs
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: