Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Firefox update from 111.0.1 to 112 set the dates of most cookies into the far future and keeps doing it

  • 8 respostas
  • 3 have this problem
  • 331 views
  • Last reply by dslayer

more options

The last update made it look like all cookies were gone, except there are still there but the dates are wrong. 90%+ of them have their "last used" date set to "in 4,137 years" (see screenshot). Websites ask to accept cookies every time Firefox is restarted, which makes them basically useless. I have to use phone authentication each time I want to check gmail on my desktop because the site acts as if it had never seen me before.

Firefox's safe mode is the same. I ran the antivirus on the whole system and it found nothing. Windows clock works fine. Other Firefox functions seem to behave like normal. Other browsers are unaffected.

I filed a bug report and I'm thinking about trying the last extended support version to see if it still happens. I backed up the whole profile and I would like to keep all my data, including the cookies.

So, what can I do to try and get this fixed fast, and possibly keep my cookies, too? Thank you very much!

The last update made it look like all cookies were gone, except there are still there but the dates are wrong. 90%+ of them have their "last used" date set to "in 4,137 years" (see screenshot). Websites ask to accept cookies every time Firefox is restarted, which makes them basically useless. I have to use phone authentication each time I want to check gmail on my desktop because the site acts as if it had never seen me before. Firefox's safe mode is the same. I ran the antivirus on the whole system and it found nothing. Windows clock works fine. Other Firefox functions seem to behave like normal. Other browsers are unaffected. I filed a bug report and I'm thinking about trying the last extended support version to see if it still happens. I backed up the whole profile and I would like to keep all my data, including the cookies. So, what can I do to try and get this fixed fast, and possibly keep my cookies, too? Thank you very much!
Capturas de pantalla anexas

Chosen solution

Alright, after having tried new profiles and settings and such, I noticed the problem stopped happening in some cases. Turns out the infinite reset of timestamps to startup time is gone when starting a completely new session. It got corrupted somehow, apparently. I hope there is no other hidden defect anywhere, though, but I'm going to go with "it's fixed" at this point.

So, if you have this problem, you should try to get rid of everything that counts as cookies and site data to force new ones to be made (using a fixed version of Firefox). Of course, if you happen to have a backup of those, you should be able to use it. And then, you bookmark your current tabs and disable the "restore tabs on startup" option to start a new session. After this, simply get your tabs back from the bookmarks and enable "restore tabs" again. That should eliminate weird timestamps behavior as seen from the cookies management viewer in the settings menu and hopefully not cause further problems.

In the end, if you only have to lose your "session" (not even your tabs) and your cookies and such, it's not that bad. I kept my profile and the rest of the data and it seems to be working normally now.

Ler a resposta no contexto 👍 0

All Replies (8)

more options

Hi, the developers are gathering information on this odd bug to try to figure out what might be causing it.

Meanwhile, I don't know whether there is a way to preserve your existing cookies and simply correct Firefox's reading of their last access date/time, or whether you will need to dump them.

Your bug report might get marked as a duplicate of that one.


I just starting reading about this bug, so I haven't seen anyone post a method to fix the data. One possibility would be to install a SQLite database browser. These typically let you view the data and, assuming you have a good backup, execute a SQL command to modify it. In theory, if the time itself, has been overwritten with nonsense, then setting all the times to, say, 4 hours ago might repair it. If I do see anyone reporting a successful edit, I'll try to post it back here.

more options

Hi! Thank you for your answer. I tried a few things but other versions of Firefox can't seem to use the right date, either, it just marks them as having been used at startup, and keeps doing this after restart so it's still corrupted. However, it doesn't always ask to re-accept cookies or re-login but it's too messy and some profile data doesn't seem to like the downgrade, as expected. Updating to 112 still turns the date back to 4000+ years into the future.

I installed DB Brower for SQlite and compared some older cookies.sqlite.bak that has normal data with the newer cookies.sqlite. And all I see in the messed up one is AB_test_privacy, atidvisitor and atuserid, 3 rows out of more than 6000 in the backup. That's some major corruption I would say. I guess it's not too bad to lose all cookies and site data, but I want to be sure that the ones work exactly right. What can I do now?

more options

Do you see any indexes in the database? If so, you could try deleting (DROPping) the index only (not the table) to see whether that makes any difference.

more options

By the way, the non-cookie site data is stored in site-specific SQLite databases under

[profile.folder]\storage\default\[URL]\

That could be relevant for some sites.

more options

I see no index in any of the cookies.sqlite files I have, everything readable is in the table moz_cookies.

I tried forcing the removal of cookies and site data and after that it can keep the cookies around and appears to work again even with version 112. But it still has that weird problem of apparently setting the last used date to the startup time at each startup, something every version I tried were doing most of the time. I'll have to retest it with remade cookies in the older version. The new cookies.sqlite does seem to have normal content in it.

I saw that's in \storage but I haven't found evidence for corruption. I'd need to know where to look exactly.

more options

There is a new update to fix the future-dated cookies bug:

more options

There is no fix for lost data. This just removed what is supposed to have caused the problem which was another fix for something else. It might have spared me the trouble if I had waited even longer before updating. I'll have to make a new profile and see what I can bring over without having the same infinite reset of the last used time for almost every cookie, among other potentially many invisible issues. I guess I should start using esr versions or such. I'll post something more if I can figure out anything worth sharing. Thank you very much.

more options

Chosen Solution

Alright, after having tried new profiles and settings and such, I noticed the problem stopped happening in some cases. Turns out the infinite reset of timestamps to startup time is gone when starting a completely new session. It got corrupted somehow, apparently. I hope there is no other hidden defect anywhere, though, but I'm going to go with "it's fixed" at this point.

So, if you have this problem, you should try to get rid of everything that counts as cookies and site data to force new ones to be made (using a fixed version of Firefox). Of course, if you happen to have a backup of those, you should be able to use it. And then, you bookmark your current tabs and disable the "restore tabs on startup" option to start a new session. After this, simply get your tabs back from the bookmarks and enable "restore tabs" again. That should eliminate weird timestamps behavior as seen from the cookies management viewer in the settings menu and hopefully not cause further problems.

In the end, if you only have to lose your "session" (not even your tabs) and your cookies and such, it's not that bad. I kept my profile and the rest of the data and it seems to be working normally now.