privacy settings not followed when closing firefox by the 'file' menu

[Jérémie78]

Binary package hint: firefox-3.0

Set the following parameters :
- home-page setting : "display last tab used"
- privacy settings > check the option "always delete personals informations when closing firefox" > then check the option "browing history"

Load a website and try :
- closing firefox using the menu "file" > "close"
- closing firefox using the "red cross button" (in the right left corner of the window)

In the first case, the website is reloaded once firefox is started again.
In the other case, the website is *NOT* reloaded once firefox is started again.

So firefox is doing 2 differents things for the same action, using different buttons.

ProblemType: Bug
Architecture: i386
Date: Mon Jun 2 22:17:40 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: nvidia
Package: firefox-3.0 3.0~rc1+nobinonly-0ubuntu1~fta2~hardy
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-17-generic i686
UnreportableReason: Ceci n'est pas un authentique paquet Ubuntu

[Darin-moz (darin-moz)]

why? what does this buy us?

[Hjtoi-bugzilla (hjtoi-bugzilla)]

I believe the automatic controlling handles issues that are more about security,
and it obviously won't be nice to always automatically clear all form data.
Hitting clear cache seems like the intuitive way to do this, although
historically this has been achieved by closing the browser window (? I never was
sure why some sites asked me to close the window). What if I don't want to close
the window? The session history shows me some useful sites I visited in this
window and I use it as a convenient way of getting back to them. I actually use
this way of getting to past URLs a lot (I can just jump over the pages that had
form posts etc. and go directly to earlier URLs).

[Darin-moz (darin-moz)]

heikki: but even if we clear form data from session history, session history
will still contain the forms from which the form data originated. moreover,
layout history state will still fill in the forms as the user last saw them, so
users would still be able to re-submit the forms if they wanted. so, i don't
see the difference between that and having session history hold onto the
accumulated form data. maybe the only difference is that the user would see the
"must re-POST" error dialog instead of a broken page (or whatever we'd show if
there wasn't form data with which to recreate the lost-from-cache page).

[Hjtoi-bugzilla (hjtoi-bugzilla)]

Hmm, maybe I stated things incorrectly. I want clear (memory) cache to clear
layout history state that includes any information I have entered (scroll state
is ok, if that is stored there, but I would be ok even if that was wiped out
too)... One more thing to make it possible to wipe out all the information about
session without closing windows or quitting the browser. Obviously needed more
in kiosk mode. I am not claiming this is a high priority, but I do think this is
a real issue.

[Darin-moz (darin-moz)]

sure, i see what you're getting at now... perhaps it almost would be better to
have a clear session history button under the prefs for session history?? but,
i still think closing the browser window is the easiest conceptually for users.

[Hjtoi-bugzilla (hjtoi-bugzilla)]

Perhaps, although I don't think it is clear to the users what session history
contains. For example, I thought it only contained the URLs (based on the text
in the pref for session history), and I thought cache contained the past pages,
including the data I had entered in forms (this is also kind of implied in the
text on the cache prefs page).

Maybe we should have clear session history button, and in addition have a
checkbox or something next to that button and clear memory cache button which,
if set, would also clear the memory cache or session history, respectively. Or
clarify things in the decriptive text. Or do both. I think we need to involve UI
designers in this issue.

[Darin-moz (darin-moz)]

yeah, we definitely need to get some UI folks to comment on this.

[Timeless-bemail (timeless-bemail)]

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

[Jo-hermans (jo-hermans)]

related to bug 11008

[Zeniko (zeniko)]

Steps to reproduce:
1. Configure Firefox to open the "windows and tabs from last time" at startup and to clear private data at shutdown
2. Load any page (for a nice effect, log into your email account)
3. Close Firefox and tell it to clear all private data (at least history and cookies)
4. Launch Firefox

Expected result:
Firefox loads blank since there should be nothing to reload, i.e. sessionstore.js has been purged at shutdown.

Actual result:
All the opened pages are nicely restored, you even remain logged in.

[Zeniko (zeniko)]

Created an attachment (id=251082)
simple fix: don't recreate sessionstore.js if there are no browser windows opened

The problem is that we force sessionstore.js to be recreated, even if there are no browser windows opened from which we could want to re-save some information (i.e. the currently still opened tabs). There should really be no reason to do this -- if private data is cleared, I wouldn't expect anything to be restored afterwards (with the exception of what I can still see before me).

Drivers: Low-risk patch which (further) improves privacy without trading any comfort.

[Zeniko (zeniko)]

... and should this be far too late for Firefox 2.0.0.2, consider this a request for blocking1.8.1.3 and approval1.8.1.3.

[Dietrich-mozilla (dietrich-mozilla)]

I think this patch is problematic because on the CPD dialog, session information is not a configurable option, so users don't know that session data will be cleared. I think this has not been a problem so far only because of this "bug" :)

If this patch is accepted, users who have this configuration (browser.startup.page=3 + CPD-at-shutdown), and currently expect their session to be restored, will suddenly lose their session data after updating.

I think that browser.startup.page=3 should trump CPD-at-shutdown unless session info is configurable via the CPD dialog.

[Dveditz (dveditz)]

What about a compromise, that session cookies/auth are cleared in this case but the list of opened tabs is retained? User will have to re-log-in to something like mail, but in general a large list of newsy/bloggy tabs won't get lost.

[Zeniko (zeniko)]

(In reply to comment #4)
> What about a compromise, that session cookies/auth are cleared in this case but
> the list of opened tabs is retained?

The problem is that we currently only react to clearing the History (which is the only one to notify observers). Implementing this would require changes outside of SessionStore.

Let's consider the use case for startup.page=3 + CPD-at-shutdown though: at first view, this doesn't make sense at all - you ask Firefox to purge _all_ History and at the same time it should retain the latest bits of it. Such a user must not only be paranoid but schizophrenic as well. ;-)

There's mainly one legitimate use of that setting constellation I could see here: if you're generally "privacy concerned", but want to keep the option of resuming selected sessions. So you set Firefox to ask you at shutdown and there you either discard the _whole_ session, or you don't discard any of it.

One other exception we might want to make is to not clear the session when the browser is only restarting. However in that case, it would IMO make more sense to not do any clearing at all. If necessary, this exception could quite easily be implemented inside SessionStore itself though (by not purging sessionstore.js when resume_session_once is true).

[Dietrich-mozilla (dietrich-mozilla)]

(In reply to comment #5)
> (In reply to comment #4)
> Let's consider the use case for startup.page=3 + CPD-at-shutdown though: at
> first view, this doesn't make sense at all - you ask Firefox to purge _all_
> History and at the same time it should retain the latest bits of it. Such a
> user must not only be paranoid but schizophrenic as well. ;-)

Dveditz's idea seems like the right direction. I talked to Beltzner and thunder about this, who noted that if the user chose both prefs, we should also clear the history for each tab, only restoring the most-recent entry.

> There's mainly one legitimate use of that setting constellation I could see
> here: if you're generally "privacy concerned", but want to keep the option of
> resuming selected sessions. So you set Firefox to ask you at shutdown and there
> you either discard the _whole_ session, or you don't discard any of it.

The problem with doing that is that the CPD dialog does not give any indication that session data will be cleared. Also, the option above doesn't require such an extreme decision.

> One other exception we might want to make is to not clear the session when the
> browser is only restarting. However in that case, it would IMO make more sense
> to not do any clearing at all. If necessary, this exception could quite easily
> be implemented inside SessionStore itself though (by not purging
> sessionstore.js when resume_session_once is true).
>

Yep, shouldn't clear at all for restarts.

[Zeniko (zeniko)]

(In reply to comment #6)
> if the user chose both prefs, we should also clear
> the history for each tab, only restoring the most-recent entry.

Might also make sense.

> the CPD dialog does not give any indication that session data will be cleared.

And IMO rightly so. That'd just be one more option users would have to care about. It makes much more sense to just clear those parts of the stored session the user is clearing anyway.

Still, this bug is about clearing everything together. So it's probably WONTFIX then. Feel free to file a bug for implementing one of the alternative suggestions -- or maybe better for doing a privacy audit of SessionStore first.

> Yep, shouldn't clear at all for restarts.

That's for another bug as well (either just for SessionStore or for CPD as a whole).

[Chris Hecker (checker-lp)]

Came visiting to file a bug about the fact that CPD doesn't clear the session store in some situations and found this but, so I guess I'll just comment here. My use-case was if firefox crashes or hangs around in the background, and then you use it normally a number of times, hitting CPD occasionally, then you can get it in a state where the next time you run, it prompts you if you want to restore the session, and if yes, it restores the session from long before the last CPD, popping up windows that are not in the history or that there should be any trace of. This is surprising, since hitting CPD implies that it clears all the state associated with the user's browsing session (and is casually advertised as such for browsing privacy). But, the sessionstore.js is another place where there is private data that is unclearable by CPD, which seems broken.

Related: https://bugzilla.mozilla.org/show_bug.cgi?id=162599

Thanks,
Chris

[Zeniko (zeniko)]

(In reply to comment #8)
> since hitting CPD implies that it clears
> all the state associated with the user's browsing session

This bug is only about sessionstore.js not being cleared _at exit_, otherwise that file should be deleted immediately when you clear your browsing history. If it isn't, that'd be worth a different bug. Before you file one, please make sure that the behavior you describe isn't due to a session managing extension, though.

One possible reason for what you observe might be bug 351551 (possibly in combination with a different bug reverting the symptoms of bug 351551 over time). AFAICT those files aren't deleted through CPD although they probably should be as well.

[Gwhuntoon (gwhuntoon)]

FireFox 2.0.0.4. About this bug, FireFox was using 50% CPU after loading any page either in normal or safe mode. What I discovered was the following - SessionStore files named like sessionstore-0000.js 0kb in size to sessionstore-9999.js all 10,000 files were 0kb in size. Once I deleted the files my CPU issues are gone. Not sure what the issue is, maybe based on the naming convention of the files no more could be created or maybe 10,000 0kb files was causing strain. Could be why people are reporting corrupt profiles or stating that creating a new profile fixed the issue, ie. nothing was fixed they just were using a clean profile. From what I hearing on the Web about FireFox being a hog etc., fixing this issue could be huge.

[Zeniko (zeniko)]

Greg: That's definitively bug 351551. Make sure your virus/malware scanner and your desktop search engine (should you have any) don't scan/index sessionstore.js.

[Zeniko (zeniko)]

This was effectively WONTFIXED in comment #6.

[Markhkamp (markhkamp)]

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8) Gecko/2007091216 GranParadiso/3.0a8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8) Gecko/2007091216 GranParadiso/3.0a8

When I close the browser with the option set to prompt me to clear private data on shutdown and browsing history is checked, the previous session's tabs are not restored.

Reproducible: Always

Steps to Reproduce:
1. Open Gran Paradiso Alpha 8 with a blank profile (I used to profile manager and not a clean install)
2. Go to Tools -> Options
3. Change the "When Gran Paradiso starts" option to "Show my windows and tabs from last time"
4. In the Privacy tab, check the box next to "Always clear my private data when closing Gran Paradiso" (leave the "Ask me before clearing private data" option checked)
5. Have any combination of tabs other than just about:blank open (I used about:mozilla)
6. Click the X to close Gran Paradiso
7. When the dialog to clear private data appears, make sure that "Browsing History" is checked and click "Clear Private Data Now"
8. Open Gran Paradiso again
Actual Results:
Gran Paradiso opens with only a blank tab.

Expected Results:
It should restore the tabs from the previous session according to the option set in Step 3.

[Zeniko (zeniko)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100705 Minefield/3.0a9pre

Confirming (although that's pretty much what I'd expect to happen - see bug 366572).

[Beltzner (beltzner)]

Dietrich - what caused this change? Although this is a Truly Strange Set of Options and we might want to reverse our decision from bug 366572, I'm primarily concerned about what caused things to change.

[Markhkamp (markhkamp)]

I don't know how the coding in Firefox works, but I think that it might be possible to fix this by having 3 separate options for clearing private data on shutdown: 1: Don't clear that item of data; 2: Clear all of that item of data; and 3: Clear the item of private data except for what is in the current session (the one that's being closed). If this were to be done, then if one setting wants the first option and another setting wants the second option, the third option would be used. If the settings conflict can't be resolved like that, then it should at least behave consistently and notify the user.

[Mike Connor (mconnor)]

My rough take on this is that privacy choices trump convenience choices. If a user has chosen to clear browsing history on shutdown, that should take precedence over restoring some subset of that data. Both are explicit user choices, the only question is which wins when there's a conflict.

[Mike Connor (mconnor)]

This is WONTFIX, IMO. I think we handled it badly in Fx2, and this is the correct priority when there's a conflict. Explicit choices around privacy should be respected in a clear way.

[Zeniko (zeniko)]

Reopening per bug 398817 comment #5.

[Zeniko (zeniko)]

Created an attachment (id=289845)
don't recreate sessionstore.js if there are no browser windows opened

This three-liner makes sure that the WONTFIX'd bug 398817 doesn't accidentally regress.

[Zeniko (zeniko)]

(From update of attachment 289845)
This patch is indeed quite useless. It seems that we simply don't get the purge-session-history notification on branch while we _do_ get it on Trunk, be it because we are now registered up to a later point or because the sanitizer kicks in at an earlier moment in the shutdown queue.

[Zeniko (zeniko)]

Closing as per bug 398817 comment#1: WORKSFORME.

[Zeniko (zeniko)]

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

[Stuartmarchant (stuartmarchant)]

There is a list of options in the "Clear private data" window, including items such as "Browsing History".
Is it not possible to add another item to that list, entitled "Active tabs and windows" or similar? This, when UNchecked, would force Firefox to comply with the "Show my windows and tabs from last time" switch, giving the user control over this behaviour and removing the conflict.

Just an idea :-)

[Aarobertxtr (aarobertxtr)]

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4

I hope the following is a bug and not something having being changed on purpose:

In FF2 I could have both the "show my windows and tabs from last time" option chosen at the same time as "Always clear my private data when I close Firefox" with the "Browser History" checked in settings and then on shutdown history is cleared and on opening tabs from last sessions are shown?

Now in FF3 Beta 4 (Portable) when I check both of these settings, then when I open FF up after having closed it: last session is not shown... only an about:blank page :(.

I am afraid that this change has been done on purpose and is not a bug. Also see #32, #35 and #37 on this page: http://www.mozillazine.org/talkback.html?article=23077

If this has been changed in newer builds/trunks (is there a difference :S) please bear with me. Reason I don't use newer version is that I prefer a portable one that does not install into my system. The latest is FF3B4: http://portableapps.com/apps/internet/firefox_portable/test . But this bug was to important to me to take the chance and not bugzilla it.
Also bear with me if it has already been bugzilla'd. I did a search - didn't find something similar.

Reproducible: Always

Steps to Reproduce:
1.Tools
2.Options
3.In 'Main' in 'When Firefox starts:' dropdown choose 'show my windows and tabs from last time'
4.In 'Privacy' check 'Always clear my private data when I close Firefox'
5.Uncheck 'Ask me before clearing private data'
6.Press the 'Settings' button and be sure to have 'browsing history' checked
(be sure to have some tabs open - not just a blank page)
7.Now close and open Firefox again
Actual Results:
You'll see that your tabs from last time are not opened, though you have the 'show my windows and tabs from last time' option chosen

Expected Results:
'show my windows and tabs from last time'
Just like in FF2

[Zeniko (zeniko)]

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

[Zeniko (zeniko)]

*** This bug has been marked as a duplicate of bug 398817 ***

[Zeniko (zeniko)]

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

[Bmathis-bugzilla (bmathis-bugzilla)]

This issue is a big concern when you have selected to "clear private data on exit", and selecting that option makes session support 100% useless. The issue with this feature is that it works differently if you are using it "on exit", or via menu option/hotkey.

The scenario for using the hotkey is this (in this scenario, the user has "browsing history" enabled as one of the items that will be cleared):
1. User is browsing sensitive material
2. User presses the hotkey to clear data.
Result:
All private data is cleared, but the tabs that are currently open are not closed, which leaves the "current" page in the history.

However, when using "clear on exit", all of the history is cleared, including the "current" item in the history, which leaves nothing to be restored on the next startup.

If a user is concerned with clearing their tabs when they close the browser, there is already an option for this where they don't enable session support in the first place. They can start the browser with their homepage or a blank page, instead of "Show my windows and tabs from last time". That is how it should be taken care of if a user wishes to disable session support.

[Stuartmarchant (stuartmarchant)]

(In reply to comment #10)

Brian I think you've misunderstood the complaint.
This isn't about wanting to disable session support - almost the opposite.
It's about being able to clear all private data on exit EXCEPT the current session, retaining the ability to restart Firefox with the last session intact.

At the moment the two settings conflict. What we are looking for is a way to enable users to have the best of both worlds. After all, not all browsing is data sensitive, and just because we don't want any private data kept doesn't mean we want to lose the session, say if one had several pages of research open.

I still stand by the simple addition of one more check box in the 'Clear Private Data' menu, called 'Current Session' or whatever.
When checked the current session would be deleted on exit, but if unchecked all data except the current session would be deleted.
What's so difficult about that? It should probably be enabled by default, but at least users would have the option to disable it and have a browser that does what it's told.

Thanks, Stuart

[Mike Connor (mconnor)]

It's really a separate bug, IMO.

[Dao (dao)]

http://hg.mozilla.org/mozilla-central/rev/2b33ad84d384

[Dao (dao)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ac7e72e97238

[Morac99-firefox (morac99-firefox)]

Based on comment 18, I filed Bug 487219 documenting the issue from comment 16 caused by this fix.

[Zeniko (zeniko)]

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

[Vseerror (vseerror)]

might complications related to multiple dispatch cause prefs dataloss as postulated in bug 422447 comment 7? (or other dataloss bugs)

[Beltzner (beltzner)]

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

[Someone (temp4746)]

This issue still exists in Firefox 3.5 final.

This is completely counter intuitive and even causes data loss!
When i press save & quit i expect it to SAVE & QUIT, Not Lose session & quit.
A user cannot know that Firefox wont save is session, because he choose to clear private data on shutdown.

[Dtownsend (dtownsend)]

(In reply to comment #5)
> This is what I think is true:

Ok this was wrong. Here is what actually goes on:

mRunning is set to true when the application event loop is started and set to false after the event loop is exited, so basically true while the app is open and responding to events from the OS.

mAttemptingQuit is set to true when Quit has been called and the application is attempting to shutdown. This shutdown is asynchronous, we must tell all windows to close and then return from Quit waiting for them to do so. mAttemptingQuit remains true until the attempt to shutdown is abandoned by a new window opening.

mShuttingDown is set to true while we are in the Quit method. If we have to exit from Quit to wait for windows to close it gets set back to false. If all Quit finds that all windows are closed then it dispatches the shutdown event and mShuttingDown remains true.

The only way to stop quit-application-granted being dispatched twice in the same session (and retain sanity) would be to move it to after the point where all windows have closed. This is the same point that we dispatch quit-application already.

The alternative would be to dispatch it as it is now when we attempt to close windows, and assuming shutdown is never aborted never dispatch it again. However in that scenario I think it would be sensible to dispatch an event when shutdown is aborted and basically say that quit-application-granted might happen again after that.

[Fischer0001 (fischer0001)]

As discussed in #458639 and here the behaviour of V3.5 is unacceptable.

The actual behaviour is misleading and it is devoid of logic.

As said before: Specific commands override the more general ones; this is PRINCIPLE in all aspects of live and engineering. In law, software-engineering, business...

An I think it is a impudence (or perseverance) to ignore constructive criticism!

I don't want to insult you!

BUT, PLEASE, DO SOMETHING! VOTE FOR IT, RECONSIDER IT! DON'T BE SO IGNORANT!

FIGTH FOR IT!

THANKS

[B3n-wallis (b3n-wallis)]

Yes, please fix this.

[Morac99-firefox (morac99-firefox)]

How can shutdown be aborted after the quit-application-granted notification goes out? That notification is only supposed to be sent when all quit-application-requested observers have agreed to allow shutdown to occur.

Basically it's supposed to be beyond the point of not return at that point in the shutdown process. If this isn't the case and shutdown is somehow aborted after a quit-application-granted notification is issued, a number of add-ons and components will get into a bad state.

[Dtownsend (dtownsend)]

(In reply to comment #9)
> How can shutdown be aborted after the quit-application-granted notification
> goes out? That notification is only supposed to be sent when all
> quit-application-requested observers have agreed to allow shutdown to occur.

Currently opening a new window will abort the shutdown process. However we've decided that once we reach this point only modal windows may be opened which will pause the shutdown process until they are closed at which point it will resume again. This change means we should be ok to leave the notification where it is and still only dispatch it once.

[Ashughes (ashughes)]

in-litmus+
https://litmus.mozilla.org/show_test.cgi?id=7802

[longsonr (longsonr)]

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

[Bugzilla-ett-idesystem (bugzilla-ett-idesystem)]

This bug remains WONTFIX despite all these comments, and it probably should be because it would definitely be a bad idea to ever NOT clear private data when that pref has been set.

Still, judging by the number of "such-and-such has been marked as a duplicate of this bug", this feature IS pretty much broken. I have filed Bug 503564 to try to get around this problem. Hope this helps.

[Marcus-ps+mozilla (marcus-ps+mozilla)]

The truly bizarre things is that this a change in expected behaviour from the previous version of Firefox (3.0.x). I had the equivalent of both these options selected in the previous version, and it worked fine, in the sense that my private information was clear to the extent that it still allowed me to restart Firefox with all the windows and tabs from last time.

Suddenly I upgrade, and find out in the most unpleasant possible way, that the beahviour changed. I don't even get a dialog box warning me that I am closing a window with multiple tabs, even though browser.tabs.warnOnClose, browser.warnOnQuit and browser.warnOnQuit are set to true.

So why would anyone want to close/quite/restart while there are windows tabs with important windows open? Simple: because they had an update on a addon, due to the upgrade to the browser, or because the browser was updated due to a security fix. Not the mention the times when Firefox may be unstable for whatever reason.

Punishing the user is not the answer.

Allowing the user to select contradictory options without a warning that the results may be different from what they expect does not sound like good design. Clearly, the number of duplicates of this bug illustrates that this is causing a lot of problems to a lot of people, and I think part of that is because of the change in behaviour between the two versions.

[Dtownsend (dtownsend)]

Created an attachment (id=395077)
patch rev 1

Per the discussion this makes quit-application-granted dispatched once. After that no non-modal windows can open and the notification will not be sent again. Since we never cancel the shutdown now we can remove the fix implemented in bug 449308.

[Zeniko (zeniko)]

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

[Marcus-ps+mozilla (marcus-ps+mozilla)]

Related to Bug 503564, I have created Bug 505548 in hopes that the preferences dialog is changed in order to make it clear to the user that the options of saving the session and clearing private data are contradictory.

[Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs)]

(From update of attachment 395077)
>diff --git a/toolkit/components/startup/src/nsAppStartup.cpp b/toolkit/components/startup/src/nsAppStartup.cpp

>@@ -461,16 +415,20 @@ nsAppStartup::CreateChromeWindow2(nsIWeb
> PRBool *aCancel,
> nsIWebBrowserChrome **_retval)
> {
> NS_ENSURE_ARG_POINTER(aCancel);
> NS_ENSURE_ARG_POINTER(_retval);
> *aCancel = PR_FALSE;
> *_retval = 0;
>
>+ // Non-modal windows cannot be opened if we are attempting to quit
>+ if (mAttemptingQuit && (aChromeFlags & nsIWebBrowserChrome::CHROME_MODAL) == 0)
>+ return NS_ERROR_FAILURE;

I so do very much want a NS_ERROR_UNAVAILABLE_SHUTTING_DOWN error code... would you like to add one to nsError.h?

[Dtownsend (dtownsend)]

(In reply to comment #12)
> (From update of attachment 395077 [details])
> >diff --git a/toolkit/components/startup/src/nsAppStartup.cpp b/toolkit/components/startup/src/nsAppStartup.cpp
>
> >@@ -461,16 +415,20 @@ nsAppStartup::CreateChromeWindow2(nsIWeb
> > PRBool *aCancel,
> > nsIWebBrowserChrome **_retval)
> > {
> > NS_ENSURE_ARG_POINTER(aCancel);
> > NS_ENSURE_ARG_POINTER(_retval);
> > *aCancel = PR_FALSE;
> > *_retval = 0;
> >
> >+ // Non-modal windows cannot be opened if we are attempting to quit
> >+ if (mAttemptingQuit && (aChromeFlags & nsIWebBrowserChrome::CHROME_MODAL) == 0)
> >+ return NS_ERROR_FAILURE;
>
> I so do very much want a NS_ERROR_UNAVAILABLE_SHUTTING_DOWN error code... would
> you like to add one to nsError.h?

I just discovered that there is already a NS_ERROR_ILLEGAL_DURING_SHUTDOWN, shall I just use that or do you want me to create another?

[Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs)]

illegal_during_shutdown sounds perfect

[Dtownsend (dtownsend)]

Landed with that change: http://hg.mozilla.org/mozilla-central/rev/f055a62bf0b0

[Dtownsend (dtownsend)]

(From update of attachment 395077)
Doesn't seem to be any fallout from this, we should take it on the branch.

[Dtownsend (dtownsend)]

Landed on the branch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/aa98fc7c4a81

[Hskupin (hskupin)]

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

[Paul-oshannessy (paul-oshannessy)]

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

[Myspacemuzone (myspacemuzone)]

Okay, now then it still doesn't make sense. When the window pops up warning that multiple tabs are open, then change the text on the button that says "Save and Quit". It is misleading. Or take it out, and just have the quit button. But it doesn't save. So just take out that button when the preference is set to clear data on shutdown.

[Mardeg (mardeg)]

Someone in the IRC channel pointed out a workaround (sorry if this is already mentioned):
Untick "Browsing history" from the "Settings for Clearing History" dialog for when Firefox closes.
THEN untick "Remember my browsing history for ..."

This will apparently still allow the "Save and Quit" prompt or the "Show my windows and tabs from last time" setting to work.

[Matti-mversen (matti-mversen)]

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

[Paul-oshannessy (paul-oshannessy)]

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

[Paul-oshannessy (paul-oshannessy)]

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

[Bmo-edmorley (bmo-edmorley)]

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

[Bmo-edmorley (bmo-edmorley)]

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

[Bmo-edmorley (bmo-edmorley)]

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

[Bmo-edmorley (bmo-edmorley)]

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

[Murks (murks)]

This bug is still present in FF11 and caused a loss of all my open tabs and neatly grouped tabs (~100), thanks a lot. This is the most annoying bug I encountered in all the years I use FF (since 1.x). This bug is marked as WONTFIX, but since it has no owner, maybe it can get a new one that recognises this behaviour as a problem.

[longsonr (longsonr)]

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

[longsonr (longsonr)]

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