Cookies should be overwritten last-recent-first

RESOLVED DUPLICATE of bug 593875

Status

()

Core
Networking: Cookies
RESOLVED DUPLICATE of bug 593875
12 years ago
8 years ago

People

(Reporter: andershol, Assigned: dwitte@gmail.com)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

12 years ago
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
(Assignee)

Updated

11 years ago
Depends on: 230933
(Assignee)

Comment 1

11 years ago
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
(Assignee)

Comment 2

11 years ago
fixed per bug 230933.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Comment 3

11 years ago
(on trunk for 1.9a6, not 1.8 branch!)
(Assignee)

Updated

11 years ago
Duplicate of this bug: 263613
(Reporter)

Comment 5

11 years ago
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
(Assignee)

Comment 6

11 years ago
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)

Updated

11 years ago
Assignee: nobody → dwitte
Status: REOPENED → NEW
(Assignee)

Comment 7

8 years ago
Duping forward.
Status: NEW → RESOLVED
Last Resolved: 11 years ago8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 593875
You need to log in before you can comment on or make changes to this bug.