Closed Bug 1827669 Opened 2 years ago Closed 2 years ago

[Cookies] Severe cookies DB corruption...

Categories

(Core :: Networking: Cookies, defect)

Firefox 112
defect

Tracking

()

RESOLVED FIXED
114 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox112 + fixed
firefox113 + fixed
firefox114 + fixed

People

(Reporter: mhtsos022, Assigned: pbz)

References

(Regression)

Details

(Keywords: regression)

Attachments

(4 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0

Steps to reproduce:

Just wanna check my emails on web-mailer...

Actual results:

I had to login again, despite the fact that had recently logged in this particular site.
Checked other sites and noticed that I was signed out everywhere, plus, on each site the cookies setting prompt (Accept/Decline) re-appeared!!

Expected results:

It seems that FF forgets the login details every time a completely new session is started (exit and restart FF): it does not keep these persistent cookies and treats them as temporary regardless of how FF settings are configured [Total Cookies Protection etc.], thus leading to severe database corruption, easily...
The newest build of FF (112) seems (before the solution below) to be treating all cookies as temporary and corrupting them on session close.
I have attached some screenshots from cookies management that it clearly displays as "Last use" in ...4.130 years (!), on some cookies (instead of sec,minutes,hours or ...whatever AGO)!
Anyway, I took the hard decision to clear all cookies and cache to no avail...
Same sh*t when new session started: 4.130 ...light years & logged out anywhere, with site cookies settings reset again!
Since clearing cookies didn't help then it was possible that the
cookies.sqlite file that stores the cookies got somehow corrupted.
I renamed cookies.sqlite to ...cookies.sqlite.WTF in my FF profile folder and BAHMMM: everything works like a charm and back to normality!
Thank you, in advance.

The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Privacy: Anti-Tracking
Product: Firefox → Core
Duplicate of this bug: 1827877

Copying over from Report on Matrix:
Possible cookie related regression in Firefox 112.
Please see https://www.reddit.com/r/firefox/comments/12j1whr/firefox_does_not_save_logins_after_update_to_1120/ - this was also confirmed by multiple users in the German Firefox support. They all have in common the exact same last access - 4,138 years in the future

The following field has been copied from a duplicate bug:

Field Value Source
Status NEW bug 1827877

For more information, please visit auto_nag documentation.

Status: UNCONFIRMED → NEW
Ever confirmed: true

:mhtsos022 thank you for the report! As we try to debug this issue, would you be willing to share the data in your about:support as well as a copy of your cookies DB? In particular we would like to see what prefs you have set to try to identify the culprit.

Flags: needinfo?(mhtsos022)
Attached file aboutsupport.txt

This is the about:support output from one affected user in the Firefox support. I'll have to ask the user if they wants to share the cookie datebase.

An alternative that would be useful if people don't want to share their DB, for people who can reliably reproduce, would be running mozregression to narrow down what broke this. There's a guide on how to do this on https://mozilla.github.io/mozregression/quickstart.html .

So far both our QA team and engineers themselves have not had any success reproducing the issue, so we're pretty stumped.

Thanks for helping us debug the issue!

Could you possibly check if this build solves the problem for you ?
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/eM-HmnA6QXWHiAoZWpe8Cw/runs/0/artifacts/public/build/target.installer.exe which i took from this try build

In order to test the new build against your existing cookies you will want to point the new build at the old profile. You may want to backup the old profile as well.

  1. To find the profile location, using the old version of fx go to the three-line button settings > help > more troubleshooting information > check Profile Directory. Note the name of the profile and back up the entire folder just in case.
  2. Install the build provided
  3. In the new fx navigate to the profile dir and point it to your old profile (noted in step 1).

It would also be a great help to get some logs if you are able to assist. For this particular problem they will need to be set from command line like so on windows x64:

set MOZ_LOG=timestamp,rotate:200,nsHttp:5,cookie:5
set MOZ_LOG_FILE=%TEMP%\log.txt "c:\Program Files\Mozilla Firefox\firefox.exe"

More details can be found here, but the cookie:5 is the important part here. If you are concerned about personal information in the logs then you can email to necko@mozilla.com.

Thanks for the help!

(In reply to ­ from comment #0)

I renamed cookies.sqlite to ...cookies.sqlite.WTF in my FF profile folder

Do you still have that original file to share privately, or alternatively would you mind opening it with either sqlite3 commandline or DB Browser For Sqlite and execute PRAGMA integrity_check on it? what's the result?

The bug is marked as tracked for firefox112 (release), tracked for firefox113 (beta) and tracked for firefox114 (nightly). However, the bug still isn't assigned.

:dmehic, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Flags: needinfo?(dmehic)
Keywords: regression
Regressed by: 1819529
See Also: → 1827988

Moving to Cookies

Component: Privacy: Anti-Tracking → Networking: Cookies
See Also: → 1828126
See Also: → 1828131
Duplicate of this bug: 1827988

(In reply to Greg Hess from comment #10)

Could you possibly check if this build solves the problem for you ?
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/eM-HmnA6QXWHiAoZWpe8Cw/runs/0/artifacts/public/build/target.installer.exe which i took from this try build

Using the target.installer.exe and renaming my old profile folder to the one created by this version did improve the situation:
Now my cookies are saved after closing and reopening firefox. (FF112 Standard Version did forget them on every relaunch)
But unfortunately all old cookies & settings from websites seem to be erased
(I also checked on older websites which i hadn't acceseed in the last week)

The first build that is affected is 20230302045723. The one before it (20230301225323) does not have the issue.
Also, it doesn't seem like the database gets corrupted: after downgrading from 112 to 111 everything works fine.

Duplicate of this bug: 1828290

(In reply to ribeco3583 from comment #17)

The first build that is affected is 20230302045723. The one before it (20230301225323) does not have the issue.
Also, it doesn't seem like the database gets corrupted: after downgrading from 112 to 111 everything works fine.

Thanks! I've reviewed the hg log and it does contain Bug 1819529 which is the main suspect for this bug and has since been backed out. Glad to hear that your cookie db is still working after the downgrade!

Since you have a profile that seems to be affected by this bug, could you please check something in your cookies.sqlite file for me? I'm curious whether it contains entries that have a very high lastAccessed or creationTime field. By very high I mean at least an order of magnitude higher than e.g. 1681640738639000. An entry 4000 years in the future would be around 64795634414000000.
The database file cookies.sqlite should be in your profile folder. You can use something like https://sqlitebrowser.org/ to open it. It also allows you to sort columns to see the highest value.

Flags: needinfo?(ribeco3583)
Assignee: nobody → pbz
Flags: needinfo?(dmehic)
Status: NEW → ASSIGNED

Updating Status flag as "fixed" by backout of bug 1819529. in the 112.0.1 dot release, 113.0b4 , and the latest 114.0a1 nightly.

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Duplicate of this bug: 1828236
Target Milestone: --- → 114 Branch

Glad you found a workaround fix & sorry for being unable to assist any further!! 😃f course, will keep you informed if I have any updates on this issue! Thank you very very much & keep up da good work - P😁WER2U

Flags: needinfo?(ribeco3583)
Flags: needinfo?(mhtsos022)
See Also: 1827988
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: