User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090204 Minefield/3.2a1pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090204 Minefield/3.2a1pre If a cookie is set with an expiry date sufficiently far in the future (somewhere between 2040 and 2050), then the "Show cookies" dialog gives the expiry as being far in the past. For example, if the cookie is set to expire on 2050-Jan-01 00:00:00 GMT, the displayed expiry is Tue, Nov 25, 1913 12:31:44 PM (GMT-5). The cookie persists through restarting Firefox, so the requested expiry date appears to be holding. Reproducible: Always Steps to Reproduce: 1. Visit a web page that sets a cookie with an expiry far in the future (such as expiry.php; see attachment). 2. Restart Firefox. 3. Open the Show Cookies dialog from Preferences > Privacy. 4. View the cookie(s) set in step 1. Actual Results: The cookie Expiry Date is indicated to be in the past, yet the cookie is still there. Expected Results: The correct (future) expiry should be displayed. The attached testcase, expiry.php, sets two cookies, one expires in 2040, one in 2050. The 2040 cookie works as expected, but the 2050 one does not.
Reporter: As I don't have PHP available, could you please post the HTTP headers of your testpage ? You can use http://web-sniffer.net There is somewhere a 32 bit overflow in the seconds from January 1, 1970
Here are the headers: Date: Thu, 05 Feb 2009 03:50:34 GMT Server: Apache/2.2.11 (Unix) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8j Set-Cookie: question=everything; expires=01-Jan-2040 00:00:00 GMT Set-Cookie: answer=42; expires=01-Jan-2050 00:00:00 GMT Content-Length: 589 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html I'm sorry I can't link to my demo page since my server is not publicly viewable. The 32-bit time_t overflow came to my mind as well, but that should mean that expirations after January 19, 2038 don't work and ones before do, but in my test, an expiration of 2040 worked correctly, so I think there may be more going on here than just a 32-bit overflow.
If the cookie persists then it should be only a display error because it would be deleted on restart.
http://zed260.free-site-host.com/expiry.php uploaded test case onto this site seems to work for me on windows cant confirm on amc though
Looks ok for me with the URL from comment#5 in Firefox 3.0.6 and Seamonkey 1.9.1 branch
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258