No warning when closing multiple tabs

Mike, I think this is a regression?

Neither deb nor I get warnings when we Cmd-q with multiple tabs open; we both have the pref set.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008021818 Minefield/3.0b4pre

Which pref, specifically?

When a single window is open, you should only get the warning about closing multiple tabs if you close the window (through the titlebar control or with cmd+shift+w). If you try to quit the app (cmd+q or using the menuItem) you should get the offer to save your tabs for next time, unless you've got the pref set to always save your tabs for next time.

The relevant prefs are:

browser.startup.page != 3 (3 means "restart with last tabs")
browser.warnOnQuit = true (means you haven't bypassed that warning)

I can't reproduce this bug, and I suspect that your settings don't match the conditions above.

We might want to morph this to "omg, it's totally unclear how you set browser.warnOnQuit to false" or even "cripes-on-burnt-toast, the various quit option interactions are a snakepit of user confusion." For either of those morphs, the OS should be "all".

(In reply to comment #2)
> When a single window is open, you should only get the warning about closing
> multiple tabs if you close the window (through the titlebar control or with
> cmd+shift+w). If you try to quit the app (cmd+q or using the menuItem) you
> should get the offer to save your tabs for next time, unless you've got the
> pref set to always save your tabs for next time.

Ah -- I can't speak for the original filer, but it sounds like I may be talking about an intentional behavioural change?

In Fx2 (with .page = 3 and .setOnQuit = true), Cmd-q would still prompt me. It sounds like you no longer want the warning to appear if the tabs will be saved anyway.

If that's true, then I'll just politely register my disapproval and move along. Cmd-q is a ridiculously easy typo for either Cmd-tab or Cmd-w, and even though session save bails me out, it's 3 minutes of my life I never get back. I see that dialog far more often than I care to admit.

But I recognize that I am not the target market, so do with that what you will.

(In reply to comment #3)
> If that's true, then I'll just politely register my disapproval and move along.

Registered. The problem is that if you click the box to "never show me this thingie again" on the quit warning, that sets .warnOnQuit to false and you're never asked again. Flip that pref back and you'll be OK.

We should, however, probably check the multiple tab warning thing at that point.

Sadly, not sure it's a blocker, though I agree that it's killer-ugly. I'm having Madhava look at seeing if we can opportunistically clean this stuff up.

(In reply to comment #4)
> Registered. The problem is that if you click the box to "never show me this
> thingie again" on the quit warning, that sets .warnOnQuit to false and you're
> never asked again. Flip that pref back and you'll be OK.

Fair enough, but that's not my case -- .warnOnQuit is already true.

Believe me, I would never click that box!

Oho. If (as I confirmed through the eye-are-sees) you have:

browser.startup.page = 3 (3 means "restart with last tabs")
browser.warnOnQuit = true (means you haven't bypassed that warning)

then this is, indeed, a regression. Marking as such and nominating for blocking.

Need to restore expected behaviour from Firefox 2, which is that when there's > 1 tab in a window, you get the appropriate warning if browser.tabs.warnOnClose is true.

(In reply to comment #6)
> browser.warnOnQuit = true (means you haven't bypassed that warning)

Nope, bypassing the warning sets browser.startup.page to 3.

At least if you choose Save and Quit ...

Created an attachment (id=311955)
much better

This rejiggers this a little so that the prefs are more clear.

browser.warnOnRestart controls confirm-on-restart (thought about merging this, but I think that's usually an explicit action now, so the datalossy case is different)

browser.warnOnQuit is now a global override to never prompt when quitting, regardless of reason, prefs, etc. This is what tinderboxen/talos already set, and its useful to have a single override for testability.

browser.tabs.warnOnClose now should cover all non-restart cases where we're closing multiple tabs. This includes quitting, closing a single window with multiple tabs, and Close Other Tabs on the tab context menu. If this pref is set, you will get a warning. If you say "never ask me again" to the quit action, it also applies to the other cases. I think that's pretty sane, and offers an undo for "never ask" that didn't previously exist because its in the UI.

(From update of attachment 311955)
>+ else if ((prefBranch.getIntPref("browser.startup.page") == 3 ||
>+ prefBranch.getBoolPref("browser.sessionstore.resume_session_once")) &&
>+ prefBranch.getBoolPref("browser.tabs.warnOnClose") == false)
> showPrompt = false;

Doesn't this mean that you'll get a warning even if browser.startup.page == 3? And in order to get rid of that warning, you'll have to uncheck "Warn me when I attempt to close multiple tabs", which means that I won't be warned when closing a window that's not the last one?

(In reply to comment #11)
>
> Doesn't this mean that you'll get a warning even if browser.startup.page == 3?

That's how it was in Fx2 (and I, for one, liked it).

I like the current trunk behavior, because of the above use case. I don't want to be warned every time I quit Firefox, but I do want to be warned when I close a window that won't be restored.

So, if that's the whole point of this bug, I think we should wontfix/invalidate it, or think about a better label for "Warn me when closing multiple tabs"...

(From update of attachment 311955)
This makes a lot of sense to me.

Dao: while I understand your concern, I think the better way to handle it would be to have an undoCloseWindow function so that you *could* turn off all warnings safely. Also, changing labels this late in the game should be avoided.

(From update of attachment 311955)
Dao, fortunately, you can just set browser.warnOnQuit to false, explicitly, and keep current behaviour. I don't think that's right for everyone though, or I would have wontfixed this already.

undoCloseWindow would be nice (although I'm not sure if I'd prefer it over being asked before the window is closed) but it doesn't exist right now, so the Fx2 way means either repeating annoyance or potential dataloss. It's great that I can work around this with a hidden pref, but that doesn't help the remaining users.

(In reply to comment #16)
> Dao, fortunately, you can just set browser.warnOnQuit to false, explicitly, and
> keep current behaviour.

Actually, from looking at the patch, I don't see how that gives me the behavior described in comment 13.

Is this actually a duplicate of bug 384907? It seems like this is still a special issue on Mac...

(In reply to comment #18)
> (In reply to comment #16)
> > Dao, fortunately, you can just set browser.warnOnQuit to false, explicitly, and
> > keep current behaviour.
>
> Actually, from looking at the patch, I don't see how that gives me the behavior
> described in comment 13.

Let me specify this: browser.warnOnQuit=false would work for /me/, because I have browser.startup.page=3. However, warnOnQuit suppresses the warning regardless of the startup page, which explains why that can't be right for everyone.

(In reply to comment #19)
> Is this actually a duplicate of bug 384907? It seems like this is still a
> special issue on Mac...

Like bug 384907, it's no coincidence that this bug was reported by Mac users. On Windows and Linux, where the bulk of our users is, you can hardly quit an app by accident. So I still think the current patch would do more harm than good. The best way would probably to address this on Mac only.

(In reply to comment #20)
> On Windows and Linux, where the bulk of our users is, you can hardly quit an
> app by accident.

Oh, I strongly disagree as I've quit apps by accident enough times. Pressing Ctrl+F4 when wanting to do something else, clicking on the wrong "close" icon on window title bar have lead me there. I also initiate (well, used to when this worked) quitting to see how many tabs I have open.

Also, some apps don't terminate and limit their visual presence to an icon in the system tray on Ctrl+F4 or the "close" icon click, which has formed a habit for me, and now I sometimes do this for apps that quite when they are told to. But because I often have tens of tabs open, I'd really like to have a chance to confirm or cancel termination.

Created an attachment (id=313257)
alternate patch

Discussed this with mconnor a bit - I'm not entirely sold on the change to make the warnOnClose pref control both quitting and window closing, but that's not really my call. This is the alternate patch that I had in mind, that should solve Phil's issue (not being prompted to quit when session saving is enabled) without affecting Dao's use case (wanting to be prompted when closing a window with tabs, but not when quitting while the session will be restored) - though users in Dao's case users will need to manually disable the Quit dialog the first time it appears, because we'd now always show it regardless of whether or not session saving is enabled.

What it doesn't do is consolidate the prefs for whether to prompt when closing tabs/windows and whether to prompt when quitting, like mconnor's patch does. In other words, it doesn't address the confusion in comment 0 about the pref shown in the "Tabs" pane not affecting the Quit dialog. I don't really think we should be making that kind of behavior change this late in the cycle.

Created an attachment (id=313263)
nets out the same as original patch, but much saner

Realizing in discussion with gavin that the current flow sucked and should be simplified down to just this.

I might as well comment on the other patch I'm obsoleting. Gavin's alternate patch doesn't solve this well, because it does two key things wrong:

1) It allows a user to toggle a behaviour, without any UI to revert that behaviour. warnOnQuit has no UI, so users have no way of reverting the behaviour if they don't like it.

2) we continue to have a poorly inconsistent UI where we don't respect the global "warn me when closing multiple tabs" pref, as we did in Fx2. If I enable that warning, it doesn't happen on quit if session restore is enabled. That caused confusion here, and we should absolutely prevent that confusion and remove the regression in consistency.

This is a regression in terms of expected and predictable behaviour from Firefox 2, which is why its a blocker. This restores the Fx2 behaviour, except that we have a single dialog that has better behaviour than the old "prompt per window" behaviour. Its not perfect, and the warnOnQuit pref remains to enable the behaviour we had in the betas, but I am not going to ship what I believe is confusing and inconsistent UI, even if we got to the fix late in the development cycle. We ship betas to uncover user issues such as this, so I think any "we can't revert behaviour" argument is fundamentally flawed. If beltzner and I agree here, I think that's good enough cause to move forward.

(In reply to comment #24)
> 1) It allows a user to toggle a behaviour, without any UI to revert that
> behaviour. warnOnQuit has no UI, so users have no way of reverting the
> behaviour if they don't like it.

To be clear, my patch doesn't cause that bug - it just doesn't fix it. Your patch fixes this by using the existing exposed warnOnClose pref instead of warnOnQuit to control quit dialog behavior in the default case.

> 2) we continue to have a poorly inconsistent UI where we don't respect the
> global "warn me when closing multiple tabs" pref, as we did in Fx2. If I
> enable that warning, it doesn't happen on quit if session restore is enabled.
> That caused confusion here, and we should absolutely prevent that confusion and
> remove the regression in consistency.

My patch addresses the lack of prompting in the Quit case with session restore enabled, except that it uses the new warnOnQuit pref (togglable in visible UI only from the Quit dialog) rather than the existing pref used for per-window dialogs. If it was combined with a patch that would expose both the warnOnQuit and warnOnClose prefs in a reasonable way, I think it would be the best choice, but exposing them both in a reasonable way is probably difficult (and would require additional string changes).

> We ship betas to uncover user issues such as this, so I
> think any "we can't revert behaviour" argument is fundamentally flawed.

By "revert behaviour" I meant "lose functionality". I am disappointed that we're going to lose the behavior that lets users distinguish between guaranteed dataloss (closing a window with many tabs, "close all other tabs") and minor dataloss (whatever session restore doesn't save - form history on SSL pages, DOM state, etc.), especially when we already effectively ignore that minor dataloss when suggesting users restart for software update or add-on installation. I think this distinction is relevant, and that the current behavior allows the decision to be made implicitly (by offering to let them disable both the Quit dialog and the "close other tabs/close window" dialog separately).

Given that information I am inclined to agree that your patch is better.

(In reply to comment #25)
> By "revert behaviour" I meant "lose functionality". I am disappointed that
> we're going to lose the behavior that lets users distinguish between guaranteed
> dataloss (closing a window with many tabs, "close all other tabs") and minor
> dataloss (whatever session restore doesn't save - form history on SSL pages,
> DOM state, etc.)

The good thing is that regressing the current trunk behavior won't disappoint Firefox 2 users. Still not satisfying for someone who knows that it can work better, though.

(From update of attachment 313263)
This also changes the behavior of the "restart" case to observe the warnOnRestart pref when session saving is enabled (startup.page==3), when it used to just restart. r=me assuming you're OK with that.

Yes, that's exactly what I meant to do. Thanks!

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

(From update of attachment 313263)
a1.9=beltzner

I'm starting to think that bug 428742 and bug 428843 are worse for users than not being able to reset the "warn on quit" pref in the UI. My alternate patch wouldn't suffer from bug 428843, and would make the workaround for bug 428742 easier to swallow (because disabling the Quit prompt wouldn't disable the warning for closing a window with multiple tabs).

I'm using Vista+SP1 and Firefox 3 RC1 en-US does not warn me when closing multiple tabs while this option is checked for sure.
Regression ?

(In reply to comment #32)
> I'm using Vista+SP1 and Firefox 3 RC1 en-US does not warn me when closing
> multiple tabs while this option is checked for sure.
> Regression ?

Given the patch in bug 428843, we've reverted to the never warning if your session will be restored. The change from this bug still applies to when session restore is disabled.

(In reply to comment #33)
> Given the patch in bug 428843, we've reverted to the never warning if your
> session will be restored.

FF is configured to restore sessions on my computer, but if have 50 tabs open, I want to be warned that I am about to close them and be given a chance to cancel this. Reopening many tabs sometimes takes a very long time, mind you. You will come back to this and redo the whole thing in the next version, right?

Both RC2 and nightly work fine in regards to this. Both display the warning when multiple tabs are open and the window is closed.

I tried this out on Vista and XP, for both RC2 and nightly.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

This doesn't happen for me.

Do you have it configured to open tabs and windows from last time?

I have it set to "Warn me when closing multiple tabs". From there, it saves it only if you click "Save and quit".

I think you have a different situation where it always remembers the last tabs without prompting to remember it, correct?

(In reply to :Gavin Sharp (email <email address hidden>) from comment #183)
> This bug has outlived its usefulness - our current warning behavior is
> weighed towards not warning, but allowing session restore if needed.

To reiterate the previous comment, restoring a browser session is functionally not equivalent to keeping the current session open in many common cases (where page content may have changed on the server, where credentials are required, etc.).

> If there are specific issues those are best dealt with in narrower bugs.

This bug documents that that Firefox does not respect the user's setting of the "warn me when closing multiple tabs" option. As that is a specific, narrow issue, your above-quoted sentence indicates that you have misunderstood this bug's purpose, and closed it based on this misunderstanding. I therefore request that it be reopened.

It would also be nice if the bug were fixed. I strongly suspect the fix would be simple and relatively quick if someone were to work on it.

Another reason restart is not equivalent is the placement of the frames and icons. I use multiple virtual desktops and when restarting Firefox all frames appear in one desktop and not in the same pattern. This may be a fault or limitation of the window manager but it's avoidable by avoiding involuntary closure of Firefox.

Gavin, does it actually work for you, or have you decided not to fix it? The comments above indicate that there is a setting which doesn't do what users expect, and that many users experience this. I'm changing the resolution to WONTFIX because that seems more accurate. Still, I think it would be preferable to actually fix this setting.

WONTFIX is probably closest to the mark, but this is working as designed. Not everyone will agree with the design, that's fine, but six years down the road I don't see any compelling rationale for changing this behaviour for the majority of users. It might make sense to tweak the wording.

I will note that browser.warnOnQuit is perhaps misnamed, as the only functionality it is intended to cover is as a hidden boolean to automatically suppress warnings when set to false. It exists to support test configurations. Setting it to true does not force a prompt, nor is that intended behaviour.

Also, downloads should resume with session restore, and session cookies for all open tabs should also be restored by default. I don't have an example where either is untrue, but if either behaviour is failing, we should file specifically scoped bugs for that issue. The other cases seem like either corner cases we can decide on in isolation (i.e. better use of cache for restoring pages).

(In reply to Mike Connor [:mconnor] from comment #189)

> I don't see any compelling rationale for changing this behaviour for
> the majority of users.

You have been given several reasons, (and only one would do).

> I will note that browser.warnOnQuit is perhaps misnamed, as the only
> functionality it is intended to cover is as a hidden boolean to
> automatically suppress warnings when set to false. It exists to support
> test configurations. Setting it to true does not force a prompt, nor is
> that intended behaviour.

It's curious that quitting a frame with multiple tabs prompts "You about to close N tabs. Are you sure you want to continue [x]Warn me when I attempt to close multiple tabs [Cancel] [Close tabs]" but not on Control+Q. If it's design it's poor.

> Also, downloads should resume with session restore,

They do not [all].

> and session cookies for
> all open tabs should also be restored by default.

I'd say that was wrong, closing the browser should end a session - privacy and security.

> but if either behaviour is failing, we should file
> specifically scoped bugs for that issue. The other cases seem like either
> corner cases we can decide on in isolation (i.e. better use of cache for
> restoring pages).

Anyone with "clear history when Firefox closes" set on will be disappointed by an involuntary closure. You must think someone uses this else it wouldn't exist!

Note, Opera has such a warning.

Please answer these specific questions:
Why do you think the behaviour should be different for frame quit vs control+Q?
What is the resistance to offering the option of the closure confirm for control+Q too?

(In reply to Mike Connor [:mconnor] from comment #189)
> WONTFIX is probably closest to the mark, but this is working as designed.
> Not everyone will agree with the design, that's fine, but six years down the
> road I don't see any compelling rationale for changing this behaviour for
> the majority of users.

People are unhappy about the behavior - just look at the number of dupes, votes, and the size of the CC list.
For every person taking the trouble to report the bug, untold thousands are cursing you under their breath.

C-q should be protected by a warning. No other major browser - Opera or Chrome - has the obnoxious behavior of dying on a typo (wiping the sessions and downloads).

> I will note that browser.warnOnQuit is perhaps misnamed,
> as the only functionality it is intended to cover is ...

If you think this option is not applicable, a new option must be added.

(In reply to Mike Connor [:mconnor] from comment #189)
> six years down the
> road I don't see any compelling rationale for changing this behaviour for
> the majority of users.

1) It is six years down the road because no one has fixed this rather simple bug in all that time. The time the bug has gone unaddressed should not be used as a rationale to continue to not address it. On the contrary, that a simple bug has not been fixed in six years -- along with the number of people who want it fixed, as Sam points out in the previous comment -- should be motivation to prioritize fixing it.

2) The behavior needn't change for a majority of users, only those users who specifically desire the warning, and so indicate in their browser preferences.

> Setting it to true does not force a prompt, nor is
> that intended behaviour.

It is a change from behavior in older versions of Firefox. Where is this change in intent documented?

> The other cases seem like either
> corner cases we can decide on in isolation (i.e. better use of cache for
> restoring pages).

It seems a whole lot simpler to just pop up a warning if the user has indicated he wants one. I'm not sure why the fix that can be done in a couple of hours, honors what the user has asked for in his preferences, and will satisfy all the people who have voted for this bug, is seen as an inferior solution to the one that will take much longer to implement and not even solve the problem (you cannot guarantee that the user has set his cache to be large enough to hold everything in every tab that's open).

(In reply to Sam Steingold from comment #191)
> People are unhappy about the behavior - just look at the number of dupes,
> votes, and the size of the CC list.
> For every person taking the trouble to report the bug, untold thousands are
> cursing you under their breath.

We do not draw conclusions solely based on volume of Bugzilla activity, and we certainly don't extrapolate that feedback across our entire user base blindly.

> C-q should be protected by a warning. No other major browser - Opera or
> Chrome - has the obnoxious behavior of dying on a typo (wiping the sessions
> and downloads).

As mentioned already in this bug, we do not "wipe sessions and downloads" on Cmd+Q.

I'm not claiming there are no problems with our existing behavior worth addressing, just that this bug is no longer a useful place to track them. There are other bugs that already cover related issues (bug 667912, bug 565567, bug 404081, bug 628156), and I encourage people to file new, narrowly focused bugs if they have specific suggestions/issues not already covered.

At a very high level, I do not think we will be changing the "avoid prompting and make it easy to restore" stance.

(In reply to :Gavin Sharp (email <email address hidden>) from comment #193)
> (In reply to Sam Steingold from comment #191)
> We do not draw conclusions solely based on volume of Bugzilla activity, and
> we certainly don't extrapolate that feedback across our entire user base
> blindly.

Nobody said that you should. This kind of rhetoric isn't very helpful.

> > C-q should be protected by a warning. No other major browser - Opera or
> > Chrome - has the obnoxious behavior of dying on a typo (wiping the sessions
> > and downloads).
>
> As mentioned already in this bug, we do not "wipe sessions and downloads" on
> Cmd+Q.

Nonetheless there's a plethora of cases that will cause data loss.

> I'm not claiming there are no problems with our existing behavior worth
> addressing, just that this bug is no longer a useful place to track them.
> There are other bugs that already cover related issues (bug 667912, bug
> 565567, bug 404081, bug 628156), and I encourage people to file new,
> narrowly focused bugs if they have specific suggestions/issues not already
> covered.

"Implement hold threshold timer"? Very discoverable. Yeah I see this very much being implemented :-/
What to say about bug 565567? It could be rephrased "implement bug 419009 but only on Mac"! Now you're getting cute. (At least the ticket contains a link to a seemingly helpful extension: https://addons.mozilla.org/en-US/firefox/addon/always-ask/ )
The other two aren't quite the same issue as this.

> At a very high level, I do not think we will be changing the "avoid
> prompting and make it easy to restore" stance.

I can't see how it is a win not to ask in a situation you'll lose either private windows, non-resuming downloads, modified inputs on "Web 2.0" pages or poorly-made old-style pages, etc.

I'm not sure why this has turned into such a crusade on the part of the dev team. This same thing happened with Pidgin when long-maintained features were arbitrarily removed. Those devs were just as insistent that the changes were good. Some were reverted, others weren't, and the project lost a lot of users as a result.

Firefox used to warn on quit in OS X. It still does in Windows and Linux. The behavior in OS X is inconsistent with the user experience in the context of both web browsers in general and Firefox specifically.

At this point the refusal to fix this is simply stubbornness. You can keep coming up with reasons, but it doesn't change the fact that the current behavior is inconsistent. The worst part is that it used to work!

(In reply to :Gavin Sharp (email <email address hidden>) from comment #193)
> As mentioned already in this bug, we do not "wipe sessions and downloads" on
> Cmd+Q.

As mentioned repeatedly by people who have experienced the bug and had just that happen to them, this is false. "Wiping sessions and downloads" may not be a design goal, but it can be a side effect of this bug.

> There are other bugs that already cover related issues

I'm interested in *this* issue, not related ones, and I'm not alone in that.

> At a very high level, I do not think we will be changing the "avoid
> prompting and make it easy to restore" stance.

You can choose whatever default behavior stance you deem best.

What is at issue here is the user's ability to control the browser's behavior through configuration settings. It doesn't seem useful to have an "ignore what the user asks for in his config" stance.

Making it easy to restore a session is a laudable goal. Crashes and other fatal failures happen, and the more straightforward it is to get back up and running, the better. The browser has gotten much better about this over time, and I'm happy there is an active effort to continue improving it.

However, comment 187, comment 190, and the last sentence of comment 192 give some reasons (likely not an exhaustive list) why restoring a session can never be equivalent to keeping an existing one open for all users. If there is a simple way to avoid having to restore at all, many users would vastly prefer this.

It’d certainly be wrong to be able to restore Private Browsing windows after quitting, wouldn’t it? At the same time, losing them is all too easy. This applies even if everything else just doesn’t seem convincing enough.

> I can't see how it is a win not to ask in a situation you'll lose either private windows, non-resuming downloads, modified inputs on "Web 2.0" pages or poorly-made old-style pages, etc.

(In reply to Flávio Etrusco from comment #194)
> Nonetheless there's a plethora of cases that will cause data loss.

(In reply to saint.snit from comment #196)
> As mentioned repeatedly by people who have experienced the bug and had just
> that happen to them, this is false.

I encourage you both to file bugs about these specific cases, if there aren't any already on file. They aren't going to get fixed in this bug.

> comment 187

Bug 372650

> comment 190, and the last sentence of comment 192

Bug 565567 and bug 667912 would mitigate most of the concerns raised there.

I'm open to other suggestions (in new bugs) on other ways to make accidental quitting more difficult, but I don't think adding a "prompt me on quit" checkbox or tying a prompt to the existing "warn on closing multiple tabs" checkbox are viable ones.

> just that this bug is no longer a useful place to track them.
> There are other bugs that already cover related issues (bug 667912, bug
> 565567, bug 404081, bug 628156), and I encourage people to file new,
> narrowly focused

bug 628156 is narrowly focused although doesn't cover session restoration unlike this one. It's also been open and ignored for 3 years. If a bug report is not a useful place to track/discuss then where is?

> bugs if they have specific suggestions/issues not already
> covered.

It's been covered. The problem is the chronic lack of resolution.

> Bug 372650

Open and unresolved for 7 years.

(In reply to :Gavin Sharp (email <email address hidden>) from comment #198)

> Bug 565567 and bug 667912 would mitigate most of the concerns raised there.

Indeed, fix this (or that because it's the same problem) and you can close a whole bunch of related reports!

(In reply to :Gavin Sharp (email <email address hidden>) from comment #198)
> I'm open to other suggestions (in new bugs) on other ways to make accidental
> quitting more difficult, but I don't think adding a "prompt me on quit"
> checkbox or tying a prompt to the existing "warn on closing multiple tabs"
> checkbox are viable ones.

Do you use OS X on a regular basis?

The default keyboard shortcut for quitting any application in OS X is Cmd+Q. The default keyboard shortcut in Firefox and other browsers to close a single tab is Cmd+W. The Q and W keys are directly next to each other on a standard QWERTY keyboard. Consequently, it is very easy to "fat-finger" the shortcut to close a tab and end up quitting the browser instead.

To make accidental quitting in OS X more difficult, there absolutely *needs* to be a confirmation prompt asking if you're sure you meant to quit your open browser session with multiple open tabs. There is no other way to confirm an accidental quit.

Your arguments as to why this isn't viable have, so far, been completely subjective and provide no technological reason why the confirm-on-quit prompt, which previously existed for many years in the OS X build of Firefox, has been removed and *cannot be added back*.

Saying "we want to favor less prompting and using session restore instead" does absolutely nothing to prevent the accidental quitting of the running browser. Nobody is demanding that a confirm-on-quit prompt be mandatory. We are stating, however, that this prompt used to exist in Firefox and has arbitrarily been removed, and such a prompt is *consistent behavior across multiple operating systems and multiple web browsers*. Every other web browser in OS X behaves in this manner. Firefox behaves in this manner in other operating systems. Firefox used to behave in this manner in OS X, and it has saved many of us from accidentally quitting an open browser session when trying to just close a tab using the default Cmd+W keyboard shortcut.

Nobody is going to point fingers at you and laugh if you swallow your pride and fix this. We will very much thank you for fixing it, because it's a huge usability problem and there is absolutely zero justifiable reason why it hasn't been fixed.

(In reply to shifuimam from comment #202)
> The default keyboard shortcut for quitting any application in OS X is Cmd+Q.
> The default keyboard shortcut in Firefox and other browsers to close a
> single tab is Cmd+W. The Q and W keys are directly next to each other on a
> standard QWERTY keyboard. Consequently, it is very easy to "fat-finger" the
> shortcut to close a tab and end up quitting the browser instead.

To be fair, this is a problem for _all_ mac os apps.
Cmd+W closes windows/tabs in all apps, and none of them asks for a confirmation on Cmd+Q.
However, in all other apps accidental quitting is not a big deal.

> Your arguments as to why this isn't viable have, so far, been completely
> subjective and provide no technological reason ...

Hear!

This discussion reminds me of the stubborn refusal of google contacts to support the iso 8601 date format (YYYY-MM-DD). Sad.

(In reply to Sam Steingold from comment #203)>
> To be fair, this is a problem for _all_ mac os apps.
> Cmd+W closes windows/tabs in all apps, and none of them asks for a
> confirmation on Cmd+Q.
> However, in all other apps accidental quitting is not a big deal.

Well, in other browsers, there's a confirm-on-quit prompt. In multi-window or multi-tab applications like Microsoft Word, if you have unsaved changes, it confirms before quitting. I can't really speak to other things like text editors, mostly because I don't use Macs much anymore.

However, I do think it's important to note that in the context of web browsers, other browsers in OS X confirm on quit, and Firefox, as has been mentioned multiple times, used to confirm on quit. That part is key - the functionality was removed, versus never being there in the first place. Hence, the program is no longer behaving as expected.

> Hear!
>
> This discussion reminds me of the stubborn refusal of google contacts to
> support the iso 8601 date format (YYYY-MM-DD). Sad.

Pidgin went through the same thing in 2008 when the UI was overhauled. They lost a lot of users as a result of the developers' refusal to even consider reverting some of the more ridiculous changes.

(In reply to shifuimam from comment #204)
> Firefox, as has been
> mentioned multiple times, used to confirm on quit. That part is key - the
> functionality was removed, versus never being there in the first place.
> Hence, the program is no longer behaving as expected.

Alas, strictly speaking, after 6 years, the program is behaving in the poor but expected manner. :-(
A fix to this bug would be an unexpected improvement. :-)

I have a feeling that this discussion is getting more and more out of hand (and ridiculous as well). I think the point a lot of people are trying to make here (myself included) is that there are situations when the USER expresses his wish to be warned before Firefox is closed (regardless of the fact whether the quit command is issued via Alt+Q, Alt+F4 or close button) by checking e.g. the "warn me when closing multiple tabs" option (or setting the appropriate variables in about:config), the user's choice should be respected. Otherwise the options (that are supposed to change the closure behavior) are there only for show. That's kind of like a light switch that doesn't turn on anything. Which begs the question that do those options (like that light switch) serve a purpose at all?

In case this "not a bug, but a feature" issue won't be fixed (and all the developers and whatnot will persist on this stubborn stance), let me point out something else too: up until now it seemed to me that one of the main goals of the Firefox developer team was to create a browser that's better than the rest on the market (especially IE). However if the "prompting on quit" capability will be left intentionally broken, it'll be for the first time in history when Firefox developers will make their flagship product worse than the others on purpose (especially compared to IE, where -upon request- a prompt is displayed both when pressing Alt+F4 or the close button). I sincerely hope that this isn't the path you want to take.

It's been previously mentioned that related issues should be discussed within separate bug entries. Does that mean that the bug I reported on (bug 944394 and which previously has been marked as a duplicate of this one) should be disassociated from this endless discussion and treated as a separate issue too?

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

To <email address hidden> and everyone else, you can install the simple "always ask" addon
https://addons.mozilla.org/en-us/firefox/addon/always-ask/
It adds an additional quit dialog that will appear when Firefox would not normally prompt (for example, when you have session restore on).
It even prompts when I by mistake shut down my windows PC and Firefox is still open.

(In reply to LL25255252 from comment #208)
> To <email address hidden> and everyone else, you can install the simple "always
> ask" addon
> https://addons.mozilla.org/en-us/firefox/addon/always-ask/
> It adds an additional quit dialog that will appear when Firefox would not
> normally prompt (for example, when you have session restore on).
> It even prompts when I by mistake shut down my windows PC and Firefox is
> still open.

Why thanks a lot! I finally got down to trying it (yeah, it's been more over 2 months, I know) and works like a charm. Only thing I'm missing is the tab count as from the original prompt (other than as a security measure against closing the browser I also used it to check the number of tabs I have open), but it's extremely helpful still. Shame on the FF developers for refusing to fix this bug due to some indecipherable and incomprehensible agenda (obvious probably only to them, nobody else). Thanks again :)

(In reply to LL25255252 from comment #208)
> To <email address hidden> and everyone else, you can install the simple "always
> ask" addon
> https://addons.mozilla.org/en-us/firefox/addon/always-ask/
> It adds an additional quit dialog that will appear when Firefox would not
> normally prompt (for example, when you have session restore on).
> It even prompts when I by mistake shut down my windows PC and Firefox is
> still open.

Thanks, but this does not work for me; I've opened an issue detailing my test cases on Windows 8 Firefox 31.0, at https://github.com/zpao/alwaysAsk/issues/8, in the hope it's addressed.

(In reply to 84user from comment #210)
> (In reply to LL25255252 from comment #208)
> > To <email address hidden> and everyone else, you can install the simple "always
> > ask" addon
> > https://addons.mozilla.org/en-us/firefox/addon/always-ask/
...
> Thanks, but this does not work for me; I've opened an issue detailing my
...

Ok, I should have read the top note: https://bugzilla.mozilla.org/show_bug.cgi?id=419009#c142
which points to the Tab Mix Plus addon by onemen and Gary Reyes at https://addons.mozilla.org/firefox/addon/1122 .
I installed that on a clean Firefox 31.0 profile and it does what I expected Firefox should do: it warns me when closing multiple tabs, even if they are in a private browsing window.

However, I still feel that unmodded Firefox should have this basic option of warning the user before potentially losing data and time (as happens to me a few times).

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

After one more such crash I've registered here just to say that this bug has been really annoying me for years!

(In reply to deviatov from comment #213)
> After one more such crash I've registered here just to say that this bug has
> been really annoying me for years!

I hate to break it to you but the bug will continue to bug you (pun intended :p) for quite some time (probably years to come if you ask me). If you'd read the stuff above you'd realize that the developers insist on NOT fixing this problem (yeah, a prime example of the "it's not a bug, it's a feature!" case). You can download the workaround addon made by LL25255252 if you want (link's in the previous posts), which might help you (at least to some extent).

(In reply to coolkoon from comment #214)

Yes, I've seen the developers' intent not to fix it above. I hope to change this opinion by joining this bug.

I use this straightforward workaround:
https://addons.mozilla.org/en-US/firefox/addon/disable-ctrl-q-shortcut/

This dead simple addon works cross-platform as a WebExtension, will "work forever in Firefox 48+" and does not require a restart:
https://addons.mozilla.org/en-US/firefox/addon/disable-ctrl-q-and-cmd-q

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

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

Since Tab Mix Plus is not working any more, is there a way to force FireFox to ask "Are you sure you want quit FireFox" or something?

I sometimes miss my target when using mice, so I exit FireFox accidentally, which is annoying.

https://searchfox.org/mozilla-central/rev/ce9ff94ffed34dc17ec0bfa406156d489eaa8ee1/browser/components/nsBrowserGlue.js#1309

> browser.warnOnQuit is a hidden global boolean to override all quit prompts
> browser.showQuitWarning specifically covers quitting
> browser.tabs.warnOnClose is the global "warn when closing multiple tabs" pref

However, this does not apply if
> The session will be restored at startup, indicated by
> browser.startup.page == 3 or browser.sessionstore.resume_session_once == true

Yes, and this is an absurd behavior. I want the browser to always ask for confirmation before quitting.

Previously it was solved by extensions "Show Quit Warning" or "Tab Mix Plus", but both are not updated to be compatible with the newest versions of FireFox.

I searched for another extension that could do it, but could not find it.

I think this has been fixed. I changed browser.sessionstore.warnOnQuit to true, have all the other warnings set to true, and when I tried to close this private browsing window it warned me. I also have 'restore previous session' set (http://kb.mozillazine.org/Browser.startup.page is 3). I didn't have this warning before, ever since it changed in like Firefox 4 or whatever. This is probably the new name for the bug, with more info: bug 550559

True; the status of this bug should be changed to "FIXED".

Finally, after eleven (!) years, I see the warning as it should have always been the case. Thanks to whoever did the fixing.

Indeed, it works for me too. To anyone wondering: the new setting is browser.sessionstore.warnOnQuit. When set to true, you'll get a warning when closing the browser even when session restore is enabled (browser.warnOnQuit still needs to be true too).
I don't know how recently this was added, but it's funny how it seems to have appeared +/- at the same time as a similar behavior in Vivaldi ^^