Closed Bug 641500 Opened 13 years ago Closed 12 years ago

browser warn on quit not respected

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
4.0 Branch
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 502908

People

(Reporter: mickrussom, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.133 Safari/534.16
Build Identifier: ftp://ftp.mozilla.org/pub/firefox/releases/4.0rc1/mac/en-US/Firefox%204.0%20RC%201.dmg

when quitting firefox (command q or with menu quit) the browser closes despite warnonquit being set and the tabs are lost. No prompt for saving tabs and windows. 

Reproducible: Always

Steps to Reproduce:
1. start 
2. open some windows and tabs
3. quit. browser quits without warning. 
Actual Results:  
see above

Expected Results:  
there should be a prompt to save tabs.
Confirming this on Ubuntu.

browser.warnOnQuit = true
browser.showQuitWarning = true

Firefox instantly closes on Ctrl-Q, Close window button (X), and File -> Quit. This is a critical dataloss bug and should be fixed asap.
You've checked that browser.showQuitWarning is still 'true' after the upgrade?  Firefox changes it back to 'false' even if you've explicitly set it true previously.  Note that despite the lack of prompt your session is saved and available from History > Restore Previous Session.

They're planning to completely scrap the quit prompt, see Bug 632271 - user choice is apparently no longer sanctioned in Firefox 4.
I confirmed the settings and restarted the browser. No matter what I do I cant get a quit prompt. 

If they are removing this option I would find that an unnecessary assault on power users.
This shouldn't be the case (and in fact works for me). Can you give more details about your situation? There are a couple cases where we don't show a quit prompt even with the pref to show it (namely restoring session, single tab, or private browsing).

(In reply to comment #2)
> You've checked that browser.showQuitWarning is still 'true' after the upgrade? 
> Firefox changes it back to 'false' even if you've explicitly set it true
> previously.

This is not true. Changes to default values of prefs do not alter user set overrides.

> They're planning to completely scrap the quit prompt, see Bug 632271 - user
> choice is apparently no longer sanctioned in Firefox 4.

Ben, I appreciate your interest in Firefox, but please keep your campaigning quieter. It impedes progress. That bug is not relevant here and in fact is not being worked on, it is merely to have on file and _might_ get worked on in the future.
>There are a couple cases where we don't show a quit prompt even with the pref to show it (namely restoring session

This might be it. I have it set to restore session on restart. Of course with 50 tabs open (thanks, Panorama), I absolutely do not want to accidentally close Firefox ever (which is very easy on Linux, because Ctrl-Q is close to Ctrl-W). It takes ages to restart it. What is the rationale to not show a quit prompt in this situation, even though I explicitly set an about:config parameter to always show it?
I think the rationale there is that it's "easy" to get those back & will happen automatically - it's not really a destructive action. Granted it's definitely inconvenient. And we know this. Bug 550559 is something we're thinking of doing. There's exploration that needs to be done. In the meantime, I wrote an extension to add a new dialog (not ideal, but it "works") to catch the cases where Firefox wouldn't prompt when quitting (https://addons.mozilla.org/en-US/firefox/addon/always-ask/)

But I'm glad to see Firefox is working how we expect it to, even if that's not exactly how others expect it to. Mick, is there a possibly a settings conflict for you as well?
> (In reply to comment #2)
> This is not true. Changes to default values of prefs do not alter user set
> overrides.

A true/false value has only two states.  If default is 'true' there's no recording that it's a user-set 'true' rather than a default 'true'.  (It would be helpful if there was.)  What I meant was that even if the user had checked in a previous version that it was 'true' (in which case it would have shown as default even if user-toggled from false) it would be 'false' (default) in RC 4.0.

> > They're planning to completely scrap the quit prompt, see Bug 632271 - user
> > choice is apparently no longer sanctioned in Firefox 4.
> 
> Ben, I appreciate your interest in Firefox, but please keep your campaigning
> quieter. It impedes progress. That bug is not relevant here and in fact is not
> being worked on, it is merely to have on file and _might_ get worked on in the
> future.

Paul, the bug submitter is unhappy that they don't get the quit dialog when they should.  You don't think the planned complete removal of that dialog is relevant?!

I consider the short, concise comment (which was actually made before you CCd yourself) fully relevant to the bug.

While it's good that an add-on exists, this is something that should be present within the browser.  Alexander Limi talks, in Bug 550559, about the dangers of "being too clever" and then falls right into that trap just lines later.  Users in a private browsing session are MORE, not less likely to want a quit warning, because they have no way of getting their data back after exit.  And users with immediate session restore on startup set will still want one, because large sessions are disruptive to restore.  Yes, there's a lot of time being wasted on this topic.  But it's coming from a dysfunctional design process, not a handful of Bugzilla comments from me!

Obviously the loss of maybe tens of millions of users' sessions is my major concern, but it's maybe worth reiterating that my revised solution - https://bugzilla.mozilla.org/show_bug.cgi?id=636777#c2 - addresses the quit dialog concerns also, while maintaining the desire for a streamlined Firefox.
Confirming on Firefox 4.0 (final) on Windows XP.

Changing platform to All/All per this and previous comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
(In reply to comment #7)
> A true/false value has only two states.  If default is 'true' there's no
> recording that it's a user-set 'true' rather than a default 'true'.  (It would
> be helpful if there was.)  What I meant was that even if the user had checked
> in a previous version that it was 'true' (in which case it would have shown as
> default even if user-toggled from false) it would be 'false' (default) in RC
> 4.0.

Ok, that wasn't what it sounded like when I read your comment, but thanks for clarifying what you meant.

That said though, browser.showQuitWarning has never existed in any default except false.

> Paul, the bug submitter is unhappy that they don't get the quit dialog when
> they should.  You don't think the planned complete removal of that dialog is
> relevant?!

Not directly no. And I'll say again, that bug is not actively being worked on in any sense nor has it been said that we're going to do it. So "planned complete removal" is kind of a lie.

Unless you are contributing to the issue in this bug (where it sounds like showQuitWarning is not being respected), then please don't comment.
(In reply to comment #8)
> Confirming on Firefox 4.0 (final) on Windows XP.
> 
> Changing platform to All/All per this and previous comments.

If you're confirming, I need to know some settings to confirm that it's bug in our expected behavior, or if it's just unexpected behavior for you (doesn't mean it's not an issue, it just wouldn't be this bug).

Preference values (via about:config)
browser.startup.page
browser.warnOnQuit
browser.showQuitWarning
browser.tabs.warnOnClose

Are you in private browsing mode?
Do you only have a single window with a single tab?
Paul, I'm not a newbie here. I had all the right settings. Actually the most "shocking" set for this behavior. However I will not use the WinXP box where I have installed Firefox 4 until Monday, so I'm reconstructing the settings from memory.

browser.startup.page [the one which restarts Firefox with the last session]
browser.warnOnQuit True
browser.showQuitWarning  True
browser.tabs.warnOnClose  True

Are you in private browsing mode? No
Do you only have a single window with a single tab? A single window with about 60 tabs (my normal way of using Firefox)
I'll add that it was not a clear installation but a fresh upgrade from Firefox 3.6.16. It was not a testing setup but a "production" desktop.


My 60 tabs survived the update and (luckily) the closing of Firefox with the "x" widget because I have made my homework and set up the "Start with the last session" Options choice (this was how I closed it). 

I used about:config to change into True anything with "warn" in connection with "quit" or "close" but the next tests gave the same result.  

I was impressed with how fast Firefox closed my 60 tabs and how fast it opened with them but the fact it did not warn me was still shocking.
(In reply to comment #12)
> My 60 tabs survived the update and (luckily) the closing of Firefox with the
> "x" widget because I have made my homework and set up the "Start with the last
> session" Options choice (this was how I closed it).

So if Firefox is set to restore your previous session at startup, then we won't show the dialog (as I mentioned in comment 4). 3.0, 3.5, and 3.6 all behaved the same way.

Unconfirming since we still haven't had a case where there should have been a dialog but it just isn't showing up.
Status: NEW → UNCONFIRMED
Ever confirmed: false
(In reply to comment #9)
> Ok, that wasn't what it sounded like when I read your comment, but thanks for
> clarifying what you meant.
> 
> That said though, browser.showQuitWarning has never existed in any default
> except false.

It must have been browser.warnOnQuit then.  Certainly, when I upgraded to a late beta it changed a value to false and I got an unexpected exit when I was trying to bring up the dialog.  And this would presumably have happened for anyone who had got the quit box back during earlier betas.  (Would happen the first time the default changed to 'false', but not subsequently.)

> > Paul, the bug submitter is unhappy that they don't get the quit dialog when
> > they should.  You don't think the planned complete removal of that dialog is
> > relevant?!
> 
> Not directly no. And I'll say again, that bug is not actively being worked on
> in any sense nor has it been said that we're going to do it. So "planned
> complete removal" is kind of a lie.

"We've now made the quit dialog not show by default. Eventually we'd like to
remove support for showing it entirely, so this is that bug."  That is a plan, and in your words.  I would prefer for you not to call me a liar.

It is relevant because having the quit dialog is important to the reporter and others reading the bug.  It's unreasonable for developers to expect other interested parties to (a) be mind-readers or (b) read through every single bug.

> Unless you are contributing to the issue in this bug (where it sounds like
> showQuitWarning is not being respected), then please don't comment.

I elicited more information on this bug, and I also maybe taught you something: that by changing a default to false you stopped the dialog displaying for everyone who'd got it back in the early betas.

I think your reaction to comments by me contains some hostility because they're by me.  Well all I've done is advocate for the user.  I have no wish to waste your time, and have not recently initiated any dialogues with you.  Since Bugzilla is, in a sense, your workplace, I will attempt to hold back on barbed comments in future.
Paul,

I see the thirty years I spent as a computer user and software developer did not prepare me for this extremely unintuitive UI decision.

Since when warnOnQuit means "warn only in case..."? 
Since when showQuitWarning means "don't show unless..."?

Maybe it does not matter anyway in a world the warning is supposed to be annihilated anyway. So the misleading config strings will go as well. 

Or in the alternative, we can leave the strings to make it marginally easier for the Add-On authors to restore the usability we are now destroying. 

One more question I ask you as a former component owner: what is your definition of UNCONFIRMED? In the time bugs were owned by men, not nobodies, the choice would be between RESOLVED/INVALID and NEW. Absolutely not UNCONFIRMED if the behavior described by the reporter is childishly easy to confirm. The way you leave the bug, you have wasted my time I used to confirm the bug and you will waste the time of other volunteers (if we still have any).

BTW, I see the  definition of UNCONFIRMED did not change that much from my times: "This bug has recently been added to the database" - not true for this bug. "Nobody has validated that this bug is true" - false per the bug report versus my and other comments. "Users who have the "canconfirm" permission set may confirm this bug, changing its state to NEW" - apparently not according to you. 

Please at least add "Read comments [such and such] before commenting" to the bug summary. Sigh.

Sorry for the rant but this b=form of bug management seems very misleading to this bugzilla oldtimer.
(In reply to comment #6)
> In the meantime, I wrote an
> extension to add a new dialog (not ideal, but it "works") to catch the cases
> where Firefox wouldn't prompt when quitting
> (https://addons.mozilla.org/en-US/firefox/addon/always-ask/)

This add-on still doesn't show the dialog when in Private Browsing Mode, is it possible to change that?

My concern is that I have clumsy fingers, and my reason for wanting the dialog is that I'll often hit ctrl+q when I don't mean it. This is most important in Private Browsing Mode, where if Firefox immediately quits, there's no way to restore my session, and it's very annoying to have to restore all the pages I was looking at to buy gifts for my loved ones by hand, and even worse when some of those pages enforce limited bandwidth usage per day.

Looking at the code, it doesn't seem like there's any way to fix this without a patch, but that may just be my lack of understanding about how add-ons work. Could this be implemented in the add-on or does it warrant a new bug?
Between 641500, 632271 and 550559, it seems clear they are hell bent on Chrome-ifying the browser by taking the most useful configuration features away. I'm shocked that this behavior cant be controlled by at least an "about:config" Reminds me of the backspace does page up and not BACK issue. 

Its like the reward for being into firefox since the beginning is to get slapped in the face as this foundation tries to do battle with safari and chrome by removing features and radically changing expected behavior.
+1, extremely annoying to accidentally press Ctrl+Q when closing a tab and have all your tabs closed without warning and no way to restore them. (Especially as I often leave a tab open for days before getting around to dealing with it.)

browser.startup.page: user set, integer, 0
browser.warnOnQuit: default, boolean, true
browser.showQuitWarning: user set, boolean, true (was false which seems odd to me)
browser.tabs.warnOnClose: default, boolean, true

Are you in private browsing mode? No.
Do you only have a single window with a single tab? Single window, many tabs.

Would be enough to make me switch back to Fx3 until this is fixed (or I guess I'd have to settle for Opera if the warning gets removed entirely!) but I'll try this extension from comment #6 first.
The situation in Firefox 4.0 (final release)

The quit dialog should come up on exit if the following conditions are met:
(a) your home page is not 'Show my windows and tabs from last time', (b)
browser.warnOnQuit is true, (c) browser.showQuitWarning is true, (d) you
have more than one tab, and (e) you're not in Private Browsing mode.

In Windows XP, subject to the above, it correctly comes up for all three exit
methods: X to close last window, 'Exit' menu item and Alt-F4 keyboard shortcut.  This is an improvement in consistency, but it still doesn't come up for 'Show my windows and tabs from last time' or, most importantly, Private Browsing mode.  This defies logic, as you can't recover from an exit from Private Browsing.  (And even more staggering is that even the add-on _called_ Always Ask doesn't ask in this case!  See Comment #16.)

HyperHacker, your issue could be specific to your operating system, caused by an add-on or specific to one profile.  Does the dialog fail to appear for all three exit methods?
Yes, no method will show the warning message. OS is Xubuntu 10.10.
(In reply to comment #20)
> Yes, no method will show the warning message. OS is Xubuntu 10.10.

Your bug may be specific to that OS.  (Note that Bug 641500 appears to relate to a designed behaviour - ie one of the idiosyncratic exceptions mentioned in Comment #19 - although the reporter never confirmed that.)  You might want to report it as a new bug.
Version: unspecified → 4.0 Branch
Hi Paul and other Mozdev,
Here's some evidence for confirmation. Messing with browser.startup.page alters the warning behavior, but not the actual startup behavior. For reference on the expected behavior, I looked here: http://kb.mozillazine.org/Browser.startup.page

CASE 0: WARNING given, restores tabs at startup
(settings as below, except) browser.startup.page 0
CASE 1: WARNING given, restores tabs at startup
(settings as below, except) browser.startup.page 1
CASE 2: WARNING given, restores tabs at startup
(settings as below, except) browser.startup.page 2

CASE 3: NO WARNING with these settings (although I would like and expect one), restores tabs at startup 
browser.startup.page 3
browser.warnOnQuit T
browser.showQuitWarning T
browser.tabs.warnOnClose T

Are you in private browsing mode? N
Do you only have a single window with a single tab? N
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.