Open Bug 973420 Opened 6 years ago Updated 4 years ago
.js cleared when restarting after setting browser .privatebrowsing .autostart to true
When that pref is set, the last session is not restored, but the sessionstore.js file gets truncated to an empty file, hence losing all of the session information. Not sure why that is. I think this is a regression.
My best guess is bug 899276.
(In reply to David Rajchenbach Teller [:Yoric] (please use "needinfo?") from comment #2) > My best guess is bug 899276. That is quite plausible!
Note that bug 973658 is how I got into this situation, you can follow the STR there if you want to reproduce this more easily.
As a solution it would be quite easy to skip |PrivacyFilter.filterPrivateWindowsAndTabs(state)| in SessionSaver._saveState() if we're shutting down with the reason being "restart". This can be done using |nsIAppStartup.restarting|. I'm not so convinced anymore that this a regression of bug 899276 because I currently don't see how this worked before. We refactored the filtering into its own module but didn't change how it works. What is the desired behavior? Should we restore private windows (probably) and private tabs (?) after a restart? Should we restore those also after a crash? The latter would mean we would have to write this stuff to disk and only filter private data on a clean shutdown. The "restore after crash" scenario is not what we want, I think. But also in the restart case we could leave traces on disk, e.g. by allocating new disk blocks (and leaving the old ones) when writing or when creating the sessionstore.bak backup copy.
(In reply to comment #5) > What is the desired behavior? Should we restore private windows (probably) and > private tabs (?) after a restart? Should we restore those also after a crash? > The latter would mean we would have to write this stuff to disk and only filter > private data on a clean shutdown. The "restore after crash" scenario is not > what we want, I think. But also in the restart case we could leave traces on > disk, e.g. by allocating new disk blocks (and leaving the old ones) when > writing or when creating the sessionstore.bak backup copy. So when you use the UI to set the pref to true, we set it and immediately restart. Before the restart, we should write down the file as we normally would (basically ignore PrivateBrowsingUtils.permanentPrivateBrowsing.) The next time that we start up, PrivateBrowsingUtils.permanentPrivateBrowsing will always return true. In that case, we should never touch the sessionstore.js file at all. When you disable this mode, we set the pref to false and restart. This means that PrivateBrowsingUtils.permanentPrivateBrowsing will return false at the end of that session. We should take care to not touch the sessionstore.js file in that case, and the next time we start up, PrivateBrowsingUtils.permanentPrivateBrowsing will be false, so we should load and use the sessionstore.js as normal. Does this make sense?
I've managed to reproduce this issue and found it's regression range. Last Good Nightly: 2013-04-12 First Bad Nightly: 2013-04-13 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-04-12&enddate=2013-04-13
Thanks Cornel for figuring out the regression range. Seems like it's not a recent regression and probably caused by bug 845681. Is this OS X only then?
Mozilla/5.0 (Windows NT 6.3; rv:30.0) Gecko/20100101 Firefox/30.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Firefox/30.0 Build ID: 20140225030201 Seems like this issue is cross-platform. I reproduced it with latest Nightly on Windows 8.1 32bit, Windows 7 64bit and Ubuntu 12.04 32bit.
OS: Mac OS X → All
Hardware: x86 → All
No longer blocks: fxdesktopbacklog
Whiteboard: p=0 → p=13
You need to log in before you can comment on or make changes to this bug.