Closed Bug 495792 Opened 12 years ago Closed 9 years ago
vanishing cookies at exit
37.16 KB, image/png
4.62 KB, text/plain
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090601 Shiretoko/3.5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090601 Shiretoko/3.5pre Everything worked fine, until I didn't try the privacy mode. I tried it, and switched back. Since then, every time FF closes, it clears the cookies. So my cookies got deleted, although I do not have the history clearing setting active, I've just tried private browsing. History is saved, but cookies gone. Even if I start the Mozilla Firefox\firefox.exe (3.0.10) istead of Mozilla Firefox 3.5 Beta 4\firefox.exe or Shiretoko\firefox.exe, it downgrades the verison, but cookies always got deleted at exit... Reproducible: Always Steps to Reproduce: 1. Once tried switching on and off private browsing. Actual Results: Deletes cookies every time on my computer, haven't tried on another. Expected Results: Keep cookies as set. Haven't tried uninstalling software.
Component: General → Networking: Cookies
Product: Firefox → Core
QA Contact: general → networking.cookies
Version: unspecified → 1.9.1 Branch
Janos, can you please try it with a fresh profile and give us some STR how we can reproduce this issue? See the following page how to create a new one: http://support.mozilla.com/en-US/kb/Managing+profiles
I couldn't reproduce that. Somewhere should be a deletecookies=true, but about:config does not show that... :( Note, that I've been using the Hungarian stable 3.0.x and when 3.5 beta4 came out, I've installed it (not overwriting the old one). I've clean installed WinXP SP3 around this February. The newest FF got installed from scratch as well, only bookmarks were imported. I've been using Adblock Plus, and some plugins, like Flash 10 and Silverlight. According to file dates, I've installed FF3.5b4 on 24th April. Since then no bugs were found, only yesterday this one. I don't remember changing settings or installing add-ons, but I've tried the Private Browsing feature, not used much, and returned to the normal workspace. The next day, powering up my PC every service asked for password...
So you have set Remember History in the privacy section of the preferences dialog?
That's right, see my setting at the provided URL address: http://img3.imageshack.us/img3/1540/settingsw.png
I have begun experiencing a similar issue -- although I never tried the privacy mode. This began happening to my Firefox profile after last night. Every exit of the browser clears all cookies. Unlike the original poster, my privacy preferences are not set to custom -- rather, they are set to "Remember History" Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Can both of you please open "about:config" in the location bar and search for privacy.clearOnShutdown.cookies? What value do you have? Since I'm still not able to reproduce this problem it would be very helpful if you can give detailed steps how to reproduce the cookie deletion with a fresh profile. See my comment 2.
Update on mine.. The cause in my case was that the firefox.exe process was not exiting completely when quitting Firefox. Firing up the application again while the other process was running gave the appearance that all cookies were gone. Checking task manager and killing the firefox.exe process before starting it again returned all of the original cookies.
So it was a false alarm. Thanks for the quick answer Rick! Janos, are you still able to reproduce the bug with the final 3.5 version?
I haven't used my computer in the summer. Now I updated my Shiretoko from "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090614 Shiretoko/3.5pre" to "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11pre) Gecko/20090906 Shiretoko/3.5.4pre" and later to "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168pre) Gecko/20090911 Shiretoko/3.5.4pre". Every single version loses cookies at exit, as it did till now. Rick's case is different, my process closes when I shut down the browser. Of course my privacy.clearOnShutdown.cookies is set to false, but I've already noted that: https://bugzilla.mozilla.org/attachment.cgi?id=380846 So as I told you in #3, I couldn't reproduce the problem with a new profile. But as I mentioned I had upgraded from Hungarian 3.0.x to 3.5 beta4 earlier. I think that might be the key. Should I keep my not right working browser, or can I uninstall it to build it fresh?
Janos, I believe it would be helpful if you could do the following check: 1. Please backup your profile first 2. Go into the profile folder and delete the profiles.ini 3. Test again if the Cookies are lost 4. Restore the profile backup What's the result of step 3? If it has been solved your problem the profiles.ini contains a pref which is responsible for the cookies removal. Would be great if you could bisect the entries in the profiles.ini to find the causing one.
1. I did save the whole %APPDATA%\Mozilla\Firefox\Profiles folder and subfolders and the %APPDATA%\Mozilla\Firefox\profiles.ini 2. done 3. Firefox started as new, asked for IE import. It has created a new profile and a new profile.ini file. Cookies were kept in this profile, but all my previous settings, bookmarks, history were gone, since this was a new profile. 4. restored profile.ini 5. loaded the old default profile. cookies are still lost everytime i close the browser :( Profile.ini file contains nothing referring to cookies but this: [General] StartWithLastProfile=1 [Profile0] Name=default IsRelative=1 Path=Profiles/adc1ql36.default Default=1 [Profile1] Name=reproduce IsRelative=1 Path=Profiles/jwmbrs8x.reproduce
(In reply to comment #12) > 3. Firefox started as new, asked for IE import. It has created a new profile > and a new profile.ini file. Cookies were kept in this profile, but all my > previous settings, bookmarks, history were gone, since this was a new profile. Big sorry! That was a really bad typo but you have luckily saved your profiles.ini. The file I wanted to point to in step 2 is the prefs.js file in that profile. It would be great when you could repeat the step.
Forgive my drive-by diagnosis, but this sounds like a corrupt cookies file (or unwritable for some other reason). rename (don't delete!) cookies.sqlite and cookies.sqlite-journal out of the way and see if that clears up the problem. If it _does_ clear up the problem, would you be willing to share those files with us? We don't yet understand why these files get corrupted sometimes and there's a chance that if we see enough of them we'll pick up the pattern. Cookie files can contain sensitive information, though, so don't attach them to this bug. If you're willing we'll figure out who is investigating that issue.
Notes before testing: That might be the case!! All my profiles (I have 3 different now) shows the same file date for .sqlite and .sqlite-journal, except my faulty-working default profile. Here, my .sqlite's file date is May 31st (wow, hello, this thread was created on 1st June!) and .sqlite-journal's last modification date is today. So, yes, you're right, .sqlite is not writeable. SOLVED. After adding .old extension to those files, some new were created when I opened a page in FF. And all those new cookies where kept after restarting the browser. The problem was caused by the unwriteable cookies.sqlite files. Yup, I'm willing to share those files with you to make a better Firefox... :) Could you show me a program, that can open those files? I'd like to make sure which data I'm handing over. If it's not sensitive, it will be shared.
They're in sqlite3 format; you can download a precompiled binary for windows from here: http://www.sqlite.org/download.html You can try running a "SELECT * FROM moz_cookies;" command within sqlite3 to look at your database, but since it's apparently corrupt, it may not work. If you're willing, you can send me the file privately (firstname.lastname@example.org); I'll use it for debugging purposes only and I won't share it with anyone. That's usually how we debug things like this, because publicly sharing cookie files isn't a good idea. :) Also, I'd note that we have code to deal with corrupt db's - it should be able to recover from this. There's a chance it's not working. It would be helpful if you could enable cookie logging to see what's going on. Instructions can be found at https://developer.mozilla.org/en/Creating_a_Cookie_Log. To do this, enable logging, start the browser, browse to a few sites, close the browser, and then email the log to me, and I'll take a look.
Or install the sqlite manager which is an extension for Firefox and offers you a nice UI: https://addons.mozilla.org/en-US/firefox/addon/5817
The whimboo suggested SQLite Manager couldn't open the cookies.sqlite file, since it is damaged. I'm hesitating to send the database file... But I've restored the corrupt cookies.sqlite file and saved the cookie-log.txt for you. It can be clearly seen, that it recognizes the bad db file... I've attached the text file to this thread. Please comment if you have further questions or wishes, I will keep my files and configuration as it is. It would be great if you could debug from the log file, but if you strongly need the .sqlite file, you have to convince me... :)
Comment on attachment 406789 [details] Automated cookie log from a corrupt cookies.sqlite access >0: Init(): db corrupt, trying again >0: >0: Init(): InitDB() gave error 80004005 That's bad. That means we're trying to delete the file and failing. :( Is your cookies.sqlite file readonly, or something? Or perhaps open by another program? Do you have antivirus software running? If you disable it, and start the browser with the corrupt file, does the log show that it successfully deleted it?
Nope, it's not read-only, nor was it opened by another program. The other program idea can't be, since I discovered the bug on 31 May and we've discovered it the last week... Unfortunately I don't have an anti-virus program, this is not my primary computer. I have no idea why it can't be deleted. As I might remember and as noted in the first post, I've tried private browsing in advance discovering this bug back in May. Do you think there is a connection to that matter?
Shawn, could this be a problem in our used version of sqlite3?
(In reply to comment #23) > Shawn, could this be a problem in our used version of sqlite3? Possible its an issue of the database is corrupted, but that'd have nothing to do with our version of SQLite.
I'll have a poke and see if I can figure out what's failing. If I can't, I might need to give you some tryserver builds with extra logging, to pinpoint it...
Hey Dan, Any progress?
Are you still seeing this? If not, we should close it out.
I've reinstalled the browser and never saw the bug again...
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Issue is Resolved - removing QA-Wanted Keywords - QA-Wanted query clean-up task
You need to log in before you can comment on or make changes to this bug.