Closed Bug 656627 Opened 13 years ago Closed 10 years ago

Session restore won't turn off

Categories

(Firefox :: Session Restore, defect)

4.0 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 552326

People

(Reporter: luto, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

I don't like session restore, so I've tried everything I can think of to turn it off.  In preferences, I changed "When Firefox starts" from "Show my windows and tabs from last time" to "Show a blank page."  In about:config, I changed these prefs:

user_pref("browser.sessionstore.max_tabs_undo", 0);
user_pref("browser.sessionstore.max_windows_undo", 0);
user_pref("browser.sessionstore.privacy_level", 2);
user_pref("browser.sessionstore.privacy_level_deferred", 2);
user_pref("browser.sessionstore.resume_from_crash", false);
user_pref("browser.sessionstore.resume_session_once", true);

(max_???_undo is suggested in http://kb.mozillazine.org/Session_Restore#Completely_disabling_session_store)

But when I have firefox running with lots of tabs open and I restart my machine from the gnome system menu, all my tabs come back.  IMO just changing the setting in the preferences screen should have been enough.

(This is arguably a security bug.  I don't want untrusted networks knowing what sites I had open when I start firefox.)

Reproducible: Always

Steps to Reproduce:
1.  Turn off session restore.
1.  Open tabs.
2.  Reboot computer.
3.  Curse.
Version: unspecified → 4.0 Branch
If you quit normally, is your session cleared?
When I quit normally, Firefox correctly shows up with a blank page on startup.  But it still writes my tabs out to sessionstore.js, and I'll attached an example.
Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110621 Firefox/7.0a1

Andy, are you still able to see this on the latest Firefox 5?
Still there in Firefox 5 as distributed by Fedora.
(In reply to comment #5)
> Still there in Firefox 5 as distributed by Fedora.

Could you attach a copy of your about:support and about:buildconfig so that we might be able to tell a difference between the Fedora version of Firefox and the vanilla version of Firefox?

Additionally, please test the latest nightly on a new profile to see if you can reproduce this issue:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
kb.mozillazine.org/Profile_manager
Reproduced on firefox-8.0a1.en-US.linux-x86_64.tar.bz2, downloaded today.

I ran firefox -ProfileManager -no-remote, created a new profile, set "When Nightly starts" to "Show a blank page", opened two tabs, and kill -9'd firefox.  When I restarted Firefox, my tabs came back.

I suspect that there are two things going on here.  First, when GNOME logs out, Firefox things it crashed (or acts the same way as it does when it crashes).  Second, Firefox restores old tabs from a crash without prompting even when the "When Firefox starts" setting isn't set to restore old tabs.

If I'm right, then the first is IMO just a bug, although whether it's Firefox's bug or GNOME's bug is unclear.

The second is annoying for the same reason that Mac OS X's startup beep depending on the volume setting the last time I used the computer is annoying.  When I start Firefox I want a clean slate, whether or not it crashed the last time I ran it.  If it gave me a pane with a "restore tabs" button, that would be fine.  But doing it without prompting is annoying.

It's extra annoying because half the time one of those tabs uses HTTP authentication, and Firefox's UI for that involves an irritating modal dialog (but that's a separate bug that I'll file).
(In reply to comment #7)
> Reproduced on firefox-8.0a1.en-US.linux-x86_64.tar.bz2, downloaded today.
> 
> I ran firefox -ProfileManager -no-remote, created a new profile, set "When
> Nightly starts" to "Show a blank page", opened two tabs, and kill -9'd
> firefox.  When I restarted Firefox, my tabs came back.
> 
> I suspect that there are two things going on here.  First, when GNOME logs
> out, Firefox things it crashed (or acts the same way as it does when it
> crashes).  Second, Firefox restores old tabs from a crash without prompting
> even when the "When Firefox starts" setting isn't set to restore old tabs.
> 
> If I'm right, then the first is IMO just a bug, although whether it's
> Firefox's bug or GNOME's bug is unclear.

There is a bug there for GNOME session ends at work here. I don't think SIGKILL is what's actually sent (at least not initially, I thought there was a session end event...)

> The second is annoying for the same reason that Mac OS X's startup beep
> depending on the volume setting the last time I used the computer is
> annoying.  When I start Firefox I want a clean slate, whether or not it
> crashed the last time I ran it.

Since this was a new profile, I'll assume browser.sessionstore.resume_from_crash was still set to true. Set it to false if you don't want the crashed session restored.

> If it gave me a pane with a "restore tabs"
> button, that would be fine.  But doing it without prompting is annoying.

If you want that, keep resume_from_crash = true and set max_resumed_crashes = 0. That sounds closest to what should "fix" your situation.

> It's extra annoying because half the time one of those tabs uses HTTP
> authentication, and Firefox's UI for that involves an irritating modal
> dialog (but that's a separate bug that I'll file).

That's probably bug 567804.

So far, you've documented expected behavior that I doubt we'll change.

(In reply to comment #0)
> user_pref("browser.sessionstore.resume_session_once", true);

This actually turns on sessionrestore for the next startup.
I was too clever.  I assumed that since I saw the same behavior with kill -9 and log out that I was seeing the same bug.  I assumed wrong.

The behavior I get when playing with max_resumed_crashes and resume_from_crash is very strange.

max_resumed_crashes == 0, resume_from_crash = false, killall -9: about:config is loaded on restart (wtf?)
max_resumed_crashes == 0, resume_from_crash = false, log out: about:config is still loaded on restart.  (so far, so good)

max_resumed_crashes == 0, resume_from_crash = true, killall -9: I get a tab asking me whether I want my tabs back.  Yay!
max_resumed_crashes == 0, resume_from_crash = true, log out: all of my tabs come back without prompting.

With Fedora's build, with max_resumed_crashes == 0, resume_from_crash = true, my tabs still come back after logging out and logging back in.

Other programs have no problem handling logout and causing a prompt before they get killed by GNOME.  Even Qt programs like LyX.


(In reply to comment #8)
> > If it gave me a pane with a "restore tabs"
> > button, that would be fine.  But doing it without prompting is annoying.
> 
> If you want that, keep resume_from_crash = true and set max_resumed_crashes
> = 0. That sounds closest to what should "fix" your situation.
> 

[...]

> So far, you've documented expected behavior that I doubt we'll change.

Off topic for this bug, but it might be friendlier for the prompt to come up if there are either too many crashes or if it's been more than, say, ten minutes since the crash, unless the preference is set to restore tabs from the last session.
Firefox 9.0.1 is here and this bug is still 100% reproducible.

It can't be hard to fix.  When Firefox starts, it must check some condition to decide what tabs to recreate.  Even ignoring any weird GNOME logout issues, that condition (whatever it is) is pretty clearly wrong.  If restoring tabs is off, tabs should not be restored.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
I don't think this is a duplicate.  bug 552326 is about weird behavior where resume_from_crash interacts oddly with GNOME.  This bug is about the fact that the session state is written out to disk in the first place.  With all of the resume options turned off, the session state file should just not exist.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: