Closed Bug 348008 Opened 13 years ago Closed 9 years ago

Cookies should be overwritten last-recent-first

Categories

(Core :: Networking: Cookies, defect)

defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 593875

People

(Reporter: andershol, Assigned: dwitte)

References

()

Details

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

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
fixed per bug 230933.
Status: NEW → RESOLVED
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 http://www.serveren.dk/cookie.php
- 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().
http://mxr.mozilla.org/mozilla/source/netwerk/cookie/src/nsCookieService.cpp#2272
thanks for testing this. we had to somewhat revert the creation time changes, so this should be reopened.
Status: RESOLVED → REOPENED
OS: Windows 2000 → All
Hardware: PC → All
Resolution: FIXED → ---
Version: 1.8 Branch → Trunk
Assignee: nobody → dwitte
Status: REOPENED → NEW
Duping forward.
Status: NEW → RESOLVED
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.