Closed Bug 502908 Opened 15 years ago Closed 5 years ago

browser.warnOnQuit = true doesn't warn on quit

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox57 - wontfix

People

(Reporter: robarnold, Unassigned)

References

Details

Attachments

(1 file)

0000-fixquit.patch make warn=true warn again
940 bytes, patch
Details | Diff | Splinter Review 
This caused me to lose 50+ tabs today on 3.5.

Steps to reproduce:
1. Create a new profile
2. uncheck Prefs -> Tabs -> Warn me when closing multiple tabs
3. Open up some tabs.
4. Close the browser (File -> Exit)

No warning appears despite browser.warnOnQuit being true. The tabs are not saved.
Yes, both prefs should set to true. I believe it always been like this from the beginning of the Quit dialog.
Here's the use case for having tabs.warnOnClose set to false and browser.warnOnQuit set to true:
I have tabs.warnOnClose set to false so that I can easily close windows via the taskbar previews in windows 7 (knowing that I can get them back through "Recently Closed Windows"). I still want to be prompted when I exit the browser to save my tabs.
This behavior was a tradeoff that we made late in the 3.0 cycle, there are a bunch of bugs that go over this in more detail (bug 433018, bug 428843). There are some open bugs that cover related issues (bug 419009, bug 443396, bug 384907). I think this is a dupe of bug 419009?

I don't think that wanting to be warned when quitting but not when closing a window is that common, though now that we have undo-close-window I guess it's more logical.
I have 

browser.tabs.warnOnClose = true
browser.warnOnQuit = true
browser.warnOnRestart = true

If I close a window with multiple tabs I get a warning dialog box. If I choose quit from the meny, I get no warning whatsoever. If I choose "restart Firefox" from the addon update window, I get no warning whatsoever.

If my privacy options are set to "Clear history at restart", even though I have all these options set to true, and even though I have an option stating "Start Firefox with the windows/tabs from last time", an addon/browser update, or a quit due to instability issues wipes out all my open windows and tabs with no hope of recovering them.

This really makes no sense to me, and there should be a safer way to ensure that the expectations of the developers and the users don't clash in this way causing loss of data.
Version: 3.5 Branch → Trunk
This problem should be resolved after Bug 550559 landed
Depends on: 550559
The reporter reports that he got no warning after doing his step 2 "uncheck Prefs -> Tabs -> Warn me when closing multiple tabs",

I get no warning after *checking* 'Warn me when closing multiple tabs'
Andre,

I just checked my browser settings and see that "browserWarnOnQuit" is true but "browser.ShowQuitWarning" is false. Is that the problem here? I have NOT made any changes in quite some time.

Thanks,

George...
perhaps dupe of bug 419009 ?
Hi,

I reported this problem a few days ago. It appears on the released version AND the beta version of FF.

I don't understand why it's still happening. I HAVE seen it work properly several times yet, here we are again with a failure.

It usually happens when I'm in a hurry and hit the wrong key by accident. As I said, I HAVE seen it work properly and am always amazed when it fails to warn me.

Could someone please explain to me why we are "here" again?

Thanks,

George...
Because this wasn't working natively, there's been an extension to do this job for a while now.
https://addons.mozilla.org/en-US/firefox/addon/warn-before-quit/

Said extension is using the legacy extension interface and will no longer work as of Firefox 57.

The author claims the APIs necessary to make this extension work in Firefox 57 don't exist (an extension can't tell the browser to quit - which he has to do after intercepting the original Quit command to put up the dialog).  https://github.com/nigelbabu/warn-before-quit/issues/16#issuecomment-322359116

It's either time to get this fixed in core, or help the extension author find the right API to finish converting it to a WebExtension.
[Tracking Requested - why for this release]: There is a workaround available for Firefox 56 and earlier.  The workaround no longer works in Firefox 57. (See comment 35).
status-firefox57: --- → affected
tracking-firefox57: --- → ?
This seems unlikely to be a priority for 57, sorry.
status-firefox57: affected → wontfix
tracking-firefox57: ? → -
(In reply to Julien Cristau [:jcristau] from comment #38)
> This seems unlikely to be a priority for 57, sorry.

I've just updated to Firefox 57 (beta), and was bitten by this again, since Warn Before Quit is gone. It's a major deficiency really. Is there any plan to work on this after version 57?
Updated link describing the behaviour from Comment 10:

https://hg.mozilla.org/mozilla-central/file/934fe0bd6062/browser/components/nsBrowserGlue.js#l1248

Also pasting it here for easier search:

> There are several cases where we won't show a dialog here:
> 1. There is only 1 tab open in 1 window
> 2. The session will be restored at startup, indicated by
>    browser.startup.page == 3 or browser.sessionstore.resume_session_once == true
> 3. browser.warnOnQuit == false
> 4. The browser is currently in Private Browsing mode
> 5. The browser will be restarted.
> 
> Otherwise these are the conditions and the associated dialogs that will be shown:
> 1. aQuitType == "lastwindow" or "quit" and browser.showQuitWarning == true
>    - The quit dialog will be shown
> 2. aQuitType == "lastwindow" && browser.tabs.warnOnClose == true
>    - The "closing multiple tabs" dialog will be shown
> 
> aQuitType == "lastwindow" is overloaded. "lastwindow" is used to indicate
> "the last window is closing but we're not quitting (a non-browser window is open)"
> and also "we're quitting by closing the last window".

----

Cases 2 and 4 are the most annoying.
why is this still broken after 9 years
> 2. The session will be restored at startup, indicated by
>    browser.startup.page == 3 or browser.sessionstore.resume_session_once == true

In my experience on Slashdot.org, reliance on session restore isn't reliable if the user has entered unsaved data into a form inserted into the DOM by script. Or should the bug instead be filed against session restore?
This bug is seriously annoying I can't even tell you how...it was fixed in FF 54 and 55, but it's back in 56 and quantum. I accidentally quit browser all the time while raging around. Please fix this finally...
I'm using FF 58.0.1 on Ubuntu 17.10.

Big picture: I keep hitting ctrl-q accidentally and losing work in progress, plus the time to restart and put all 9 of my FF windows on the correct workspaces. (It's an organizational thing.)

Having ctrl-q warn on exit would, at least, let me click "no", as a workaround to binding "Quit" to some other, less-likely-to-be-hit-accidentally key.

But, it doesn't work, and I can't remap ctrl-q.

I DON'T want to be warned. When I really do want to exit, I don't want to be warned that I'm closing all my tabs (on all my FF windows).

I WANT to be warned about hitting trying to quit via ctrl-q.

I have:
browser.showQuitWarning = true
browser.warnOnQuit = true
browser.tabs.warnOnClose = true
browser.tabs.warnOnCloseOtherTabs = true

P.S. I didn't, knowingly, set the last two browser.tabs options to true.
(In reply to Damian Yerrick from comment #42)
> > 2. The session will be restored at startup, indicated by
> >    browser.startup.page == 3 or browser.sessionstore.resume_session_once == true
> 
> In my experience on Slashdot.org, reliance on session restore isn't reliable
> if the user has entered unsaved data into a form inserted into the DOM by
> script. Or should the bug instead be filed against session restore?

It should not be filed against session restore. It's a usability bug caused by *quitting without confirmation*. You can't possibly restore every single case. Even worse, take some WebGL games for instance or anything the like. Restoring is simply irrelevant, if real-time activity is disrupted by invalid quitting. So in general case, this idea of "restore rather than prevent quitting" is invalid.

This shouldn't be even a forced behavior. I.e. it can be made configurable. Those who want will have the confirmation, and those who don't want can turn it off.
Have all of this set to true and still no warning on quit by ctrl+q, Firefox 60.0.2
 
browser.warnOnRestart
browser.warnOnQuit
browser.tabs.warnOnOpen
browser.tabs.warnOnCloseOtherTabs
browser.tabs.warnOnClose
browser.showQuitWarning
"Warn you when closing multiple tabs" in preferences tab
For those of us that don't want to have to restore from session each time they accidentally hit CMD-Q (and I do frequently because the Dvorak keyboard layout puts the Q right above the Command key; the only downside to using this layout), I regained my sanity by installing

    https://addons.mozilla.org/en-US/firefox/addon/disable-ctrl-q-and-cmd-q/

This add-on disables the Cmd-Q shortcut altogether. You can still quit Firefox, but you have to explicitly use the Firefox -> Quit menu item to do so.
In general, why is it so complicated to have one working setting that mandates confirmation for quit? I don't really get what prevents it.
This bug is shortly coming up on it's 10th birthday, and is beginning to sound like the The Windows Shutdown crapfest: https://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html
This is something that probably takes 10 minutes to fix and causes people to lose data in their open tabs. But I guess every dev here is too busy trying to clone chrome to bother.
found the bug
there was a second OR-condition that cancelled out the warning message if session restore is turned on, instead instantly closing the browser
removing this condition fixes the issue

maybe we finally can put this 10-20 year old issue behind us now c:
Yumekui,

You are the master!

I look forward to testing this fix when it hits "production".

THANKS for all your efforts,

George...
Hope the fix is not yet in the 63.0b1 (64-bit) because on such version I still have the problem.
I've got the 63.0b2 and it is still not working. Is that normal the fix in not in there or the bug report has to be reopened?
(In reply to Rik from comment #56)
> I've got the 63.0b2 and it is still not working. Is that normal the fix in
> not in there or the bug report has to be reopened?

one of the mozilla maintainers would have to accept and/or apply the patch first I guess
I just applied the fix to my own install of firefox by compiling it
I do not have any access to merging changes into the firefox codebase

BUT it was a pretty tricky fix to make (at least for me c:) so I would not be surprised if it takes a pretty long while for stuff to happen while the maintainers look into how the fix works trying to figure it out.
(In reply to YumekuiNeru from comment #57)

> one of the mozilla maintainers would have to accept and/or apply the patch
> first I guess

You might want to identify the appropriate maintainer and tag them as a review request.

Take the “hg log” for the file you touched, look for a name that is most frequently mentioned as the reviewer in existing commits. It usually looks like “r+ <somebody>” in the commit summary line.
Attachment #9004028 - Flags: review?(dluca)
The bug is currently unassigned, so it means that no one from Mozilla or contributors is working on upstreaming the patch. May be someone should acknowledge first, that the patch is acceptable.
Comment on attachment 9004028 [details] [diff] [review]
0000-fixquit.patch make warn=true warn again

Redirecting to someone who works on the Firefox frontend.
Attachment #9004028 - Flags: review?(dluca) → review?(gijskruitbosch+bugs)
Comment on attachment 9004028 [details] [diff] [review]
0000-fixquit.patch make warn=true warn again

Thanks for the suggested patch.

There's a plan and UX design in bug 550559, and that'll involve more work than just changing this check. I'd take an updated patch in that bug (I'll dupe this over in a sec). It looks like you'd need to also update the label in the preferences ( https://searchfox.org/mozilla-central/rev/c3fef66a5b211ea8038c1c132706d02db408093a/browser/components/preferences/in-content/main.xul#88-89 - change the identifier for l10n there, and change the identifier and string in https://searchfox.org/mozilla-central/rev/c3fef66a5b211ea8038c1c132706d02db408093a/browser/locales/en-US/browser/preferences/preferences.ftl#179-181 ), and there may be some automated tests that need adjusting.

I'm also not sure what branch you wrote this patch against - but it wouldn't apply against nightly, because the code has changed and also checks the warnOnClose pref now (which it should probably keep doing, at least for now).

Finally, for your next patch, please could you post something generated by `hg export` or `git show` instead of just the diff, so that the commit properly credits you and includes a summary of the change (ie commit message). Thank you!
Attachment #9004028 - Flags: review?(gijskruitbosch+bugs)
Status: NEW → RESOLVED
Closed: 6 years ago
No longer depends on: 550559
Resolution: --- → DUPLICATE
The fix for Bug 550559 did not end up resolving this issue, browser.warnOnQuit = true still does not work with browser.tabs.warnOnClose = false.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Really? This bug is still present 8 years after I quit when it wasn't fixed? Why am I not surprised? Glad I switched but am tired of getting emails related to this bug. I thought I unsubbed to them all but I guess there's more.
I can't see any difference. Still not working.
(In reply to Kestrel from comment #65)
> The fix for Bug 550559 did not end up resolving this issue,
> browser.warnOnQuit = true still does not work with browser.tabs.warnOnClose
> = false.

After bug 1506173, there's now a separate pref, browser.sessionstore.warnOnQuit , which you can use to have a quit warning if you have session restore enabled. There's also a checkbox in the prefs/options for this feature.

If session restore is not enabled, browser.tabs.warnOnClose still governs whether you get a confirmation warning (if there are multiple tabs).

We don't intend to add a third, separate pref/warning for people who *do* want to have a quit warning, *don't* turn on session restore, and *don't* want warnings when closing windows / multiple tabs (ie making browser.tabs.warnOnClose = false + no automatic session restore + browser.warnOnQuit = true show a dialog is not something we're interested in doing. The "point" of the warning is to avoid losing tabs that you can't currently see / may have forgotten you had; from that perspective, wanting a warning for quitting but not for closing a window with multiple tabs doesn't really make sense).

Keeping this bug open doesn't really make sense given we've fixed part of it and don't want to make further changes as implied by the bug. But we don't have a "partly fixed" resolution value. So to close this, I have to pick an imperfect resolution value. I'm going to go with "works for me", because the more recent comments here, as well as the proposed patch, are all about the case where people *do* have session restore enabled, which now has an option (that is also exposed in the preferences/options, not just about:config) to do what this bug wants.
Status: REOPENED → RESOLVED
Closed: 6 years ago → 5 years ago
Resolution: --- → WORKSFORME
we need to save on close (In some cases, not always)
We are not interested to turn in the options and each time select or deselect the option.
I can confirm, that setting browser.sessionstore.warnOnQuit = true fixes this for me. The browser won't close down without a warning when hitting Ctrl+Q! Thanks for finally fixing it.

The workaround has stopped working for me in Firefox 66.0.3.
I have both
browser.showQuitWarning true
browser.warnOnQuit true
Other user reports the same behavior here

(In reply to aguadopd from comment #71)

The workaround has stopped working for me in Firefox 66.0.3.
I have both
browser.showQuitWarning true
browser.warnOnQuit true

See the comment right before yours:

(In reply to Shmerl from comment #70)

I can confirm, that setting browser.sessionstore.warnOnQuit = true fixes
this for me.

(In reply to aguadopd from comment #71)

Other user reports the same behavior here

and the first part of the answer which has that comment:

https://superuser.com/a/1352295

Firefox >= 65

browser.sessionstore.warnOnQuit true
browser.warnOnQuit true

If those don't work, file a separate bug with the contents of about:support (Help > Troubleshooting Information).

(In reply to :Gijs (he/him) from comment #72)

My bad, so sorry for the sloppy report. I copied the wrong name, as browser.showQuitWarning doesn't even exist.
I indeed have both browser.sessionstore.warnOnQuit and browser.warnOnQuit on true.
Just tried this on 66.0.5 and it's the same.

Was about to report a new bug but in comment #68 you explicitly say

We don't intend to add a third, separate pref/warning for people who do want to have a quit warning, don't turn on session restore, and don't want warnings when closing windows / multiple tabs (ie making browser.tabs.warnOnClose = false + no automatic session restore + browser.warnOnQuit = true show a dialog is not something we're interested in doing. The "point" of the warning is to avoid losing tabs that you can't currently see / may have forgotten you had; from that perspective, wanting a warning for quitting but not for closing a window with multiple tabs doesn't really make sense).

So it seems to be working as you expect. Probably the previously mentioned workaround was still working some versions ago. Until something else appears (maybe custom shortcuts?) I'll go with browser.tabs.warnOnClose... it's just one key press more to quit, so no big deal. The workaround of changing Ctrl+q at system level is not an option.

Thank you, have a great Sunday!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: