Closed Bug 348008 Opened 13 years ago Closed 9 years ago

Cookies should be overwritten last-recent-first


(Core :: Networking: Cookies, defect)

Not set





(Reporter: andershol, Assigned: dwitte)




User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20060728 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20060728 Firefox/

It seems that Firefox will keep a maximum of 50 cookies for a site. But when the limit has been reached and a new cookies added, the *last* cookies to be set is removed to make room for the new new cookie. This causes problems for at site where a new cookie is added for each thread read in a webforum: When 50 threads have been read, there won't be room for username/password (yes, it's a bad design, but is real).

In contrans IE (although only saving a maximum of 20 cookies) removes the *first* cookie to be set.

Reproducible: Always

Steps to Reproduce:
1. Go to the demonstration url
2. Hit "Auto 1-50" which will set 50 cookies with increasing names and random expiration times.
3. Hit "Next" to add an addtional cookie.

Actual Results:  
The last cookie "c50" is replaced by the new cookie.

Expected Results:  
The first cookie "c1" should be removed and the new cookie added to the end (as in IE).

Note that
- The expire time don't influence the removal of the cookies in this case where store overflows.
- In IE it is not the position in the list that determince when a cookie is removed. It is the start time. If a cookie in the beging of the list is updated (and having its set-time increased) it will stay in the list while cookies following it will be removed (eg. hit "Clear all cookies", hit "Auto 1-50", hit "32", hit "51" and "Next" a couple of times. Note that "c32" stays at the front of the list)
Component: General → Networking: Cookies
Product: Firefox → Core
QA Contact: general → networking.cookies
Version: unspecified → 1.8 Branch
Depends on: 230933
nice testcase! thanks for the detail here. ;)

when bug 230933 lands, this will be fixed by collateral, since we'll be keeping track of cookie age by creation time. confirmed your testcase now works on a build with that patch.
Ever confirmed: true
fixed per bug 230933.
Closed: 13 years ago
Resolution: --- → FIXED
(on trunk for 1.9a6, not 1.8 branch!)
Duplicate of this bug: 263613
Using 3.0 beta 2, it seems that it is not always the oldest cookie that is removed when adding cookies beyond the maximum allowed number of cookies. To reproduce:
- Load the test url
- Hit "Clear all cookies" to reset.
- Hit "Auto 1-50" to set 50 cookies (which is the maximum allowed number of cookies) named "c1" to "c50".
- Hit "Next" several times to add additional cookies.

Notice that the first cookies to be removed are "c1", "c2" and "c3" as expected, but after 10-20 cookies, suddenly cookies start being removed at another "random" location. I've amended the test to highlight discontinuities in the cookie names with a red bar.

Browsing through nsCookieService it seems that in findOldestCallback, which is being used by AddInternal (through FindOldestCookie), CreationID() should perhaps be used instead of LastAccessed().
thanks for testing this. we had to somewhat revert the creation time changes, so this should be reopened.
OS: Windows 2000 → All
Hardware: PC → All
Resolution: FIXED → ---
Version: 1.8 Branch → Trunk
Assignee: nobody → dwitte
Duping forward.
Closed: 13 years ago9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 593875
You need to log in before you can comment on or make changes to this bug.