348008 - Cookies should be overwritten last-recent-first

Status: RESOLVED DUPLICATE of bug 593875

(Core :: Networking: Cookies, defect)

Description

[andershol]

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)

Comment 1

[[e-mail]]

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.

Comment 2

[[e-mail]]

fixed per bug 230933.

Comment 3

[[e-mail]]

(on trunk for 1.9a6, not 1.8 branch!)

Comment 5

[andershol]

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

Comment 6

[[e-mail]]

thanks for testing this. we had to somewhat revert the creation time changes, so this should be reopened.

Comment 7

[[e-mail]]

Duping forward.