User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030319 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030319 This feature would expire a cookie once it hasn't been used for 'x' days. This is different from the current "maximum lifetime" feature in that a cookie limited with maximum lifetime will expire 30 days after it's created whether it is being used or not unless the webpage refreshes it. Reproducible: Always Steps to Reproduce:

are you sure they're not really the same thing? when you set the max lifetime of a cookie, if the site doesn't update the cookie within that period it'll be deleted. if you 'use' the site before then, typically the site will re-set the cookie (or update it) and its expiry time will be renewed again. so if you have a fixed cookie lifetime, expiry and last-used times are really just the same information. the only case this wouldn't apply, is if a site didn't update/re-set the cookie when you use the site. can you cite specific examples of this? i wouldn't imagine it to be very common, but i could be wrong.

Not very common ? On the contrary : updating cookies is very rare. Most sites will set a cookie once and never update it (becuase they want an 'infinite' lifetime), or when they think they should update it (because it's close to the expiration-date that they've set themselves). *Not* on every access ! The result is that you won't see any updates, especially if you have set a 'maximum lifetime' that is much shorter. An example: slashdot.org : I have a 'maximum lifetime' set to 7 days, and I have to login every week again (which will set the cookie).

in that case, i stand corrected. thanks for the example (though to be honest, it's not a very conducive one... ;) not sure how we should implement this. do we want to keep adding default prefs and keep bloating the backend? or should we implement some kind of js (or C...) 'helper function' that takes care of all expiry operations, on a periodic basis? this way, it's easy to change between browsers (firebird, moz etc), and it's easy for embeddors to roll their own pref setup. we already have the framework for this, in nsICookiePermission. it's a wrapper for the permissions backend, specific to cookies. we could also delegate all the default prefs to it (which would make a lot of sense); so basically nsCookieService::CheckPrefs() would shift into this service. in addition, we could add a helper function IsCookieLive() that simply returns if a cookie should be kept in the list. we would call this in several places: in SetCookie() when initially setting a cookie; in GetCookie() when checking if we can return a cookie; and in RemoveExpiredCookies() when we want to purge the list of 'non-live' cookies. so now, the concept of an 'expired' cookie is arbitrary: it doesn't have to relate solely to expiry time; it can be anything the embeddor desires, e.g. encompassing this last-accessed-greater-than expiry method. the only issue i see would be perf. for checking a single cookie it's no problem; but in RemoveExpiredCookies() we enumerate over the list and would callback this IsCookieLive() function. this is not done often so it's no really big deal; but we should make sure the function call is relatively efficient (i.e. non-virtual?). if cookie core lived in necko, and nsICookiePermission lived in some xpfe/components/ somewhere, would this still be the case? comments welcome.

dwitte: a callback is by definition "virtual" either via a virtual class method or a function pointer. both are really the same thing ;-) i'd personally punt on this feature unless said refactoring could help with other bugs.

I believe that the current cookies are 'expired' when Mozilla starts, and we also check when we access the cookie. Expiring old cookies isn't something that has to be done contantly, we can keep it in the application startup, and maybe in an extra thread that runs every 24 hours or so. There's no need to check it on every access, because the acces itself is the proof that the cookie is alive. Just keep a access-timestamp (bug 161000), and we can call the expiration routines once a day or so. You would need an extra preference (maximum staleness ?), unless you want to reuse the maximum expiration preference. But then it would only work for people who know why they need a maximum expiration. If we have a separate preference, then we can also provide a reasonable default value (30 days ?). I always thought that expiring cookies on the access-timestamps was much better than the expiration timestamp stored in the cookie itself. Most websites uses stupid expiration times like 1-jan-2010 or 2038 or whatever, but the result is that we have to process thousands of cookies, most which will be never be seen again. Limiting the expiration time to 30 days or less is much better, and when you limit it a very short time (1 day - 1 week), it's also good for your privacy. But the disadvantage is that most websites are too stupid to update their cookies on every access (it's not neccessary in IE anyway). When we keep a access-timestamp, and we purge cookies that haven't been accessed in a month or so, then we can clean the cookie-database much more intelligently - without the update-problems that can be seen now. This is not just an enhancement, this is a sign of an intelligent application.

darin: ok ;) >I believe that the current cookies are 'expired' when Mozilla starts, and we >also check when we access the cookie. Expiring old cookies isn't something that >has to be done contantly, we can keep it in the application startup, and maybe >in an extra thread that runs every 24 hours or so. There's no need to check it >on every access, because the acces itself is the proof that the cookie is >alive. >Just keep a access-timestamp (bug 161000), and we can call the expiration >routines once a day or so. re not expiring cookies constantly - that's basically what I said. that's not really an issue. however, i disagree with your statement about not needing to check expirytime on every access. we can't send back expired cookies - that's simply broken. we must check such things before sending a cookie. any other expiry operations are optional, and we do them only when required for list maintenance purposes, or when favorable for mem footprint. (well, currently that's not the case, but it will be when the rest of the rewrite lands) >You would need an extra preference (maximum staleness ?), unless you want to >reuse the maximum expiration preference. But then it would only work for people >who know why they need a maximum expiration. If we have a separate preference, >then we can also provide a reasonable default value (30 days ?). right. >I always thought that expiring cookies on the access-timestamps was much better >than the expiration timestamp stored in the cookie itself. Most websites uses >stupid expiration times like 1-jan-2010 or 2038 or whatever, but the result is >that we have to process thousands of cookies, most which will be never be seen >again. Limiting the expiration time to 30 days or less is much better, and when >you limit it a very short time (1 day - 1 week), it's also good for your >privacy. But the disadvantage is that most websites are too stupid to update >their cookies on every access (it's not neccessary in IE anyway). When we keep >a >access-timestamp, and we purge cookies that haven't been accessed in a month or >so, then we can clean the cookie-database much more intelligently - without the >update-problems that can be seen now. what do you mean, it's not necessary in IE? does it automatically update expirytimes when you access a cookie? >This is not just an enhancement, this is a sign of an intelligent application. it's an interesting RFE. i don't like the idea of bloating our backend for every little pref users may want, so i suggested the idea of making it easily customizable (so embeddors don't need to pay the price), but that doesn't get around the bloat/UI for that extra pref. the concensus is that limiting expirytime is sufficient for now. so, it can stay as an RFE. ;)

FWIW, my personal opinion is that this should be implemented instead of the "limit expire time" option -- It's designed to accomplish almost the same thing, but this is somewhat more intuitive to what end users seem to expect. In my experience advertising tracking cookies tend to reset themselves every time regardless of whether or not the cookie was already set, but typical "Rememeber my login" cookies aren't reset automatically, the server only sets the cookie when the browser doesn't already have the correct cookie set. My goal with this RFE is to allow "Remember my login" type cookies on sites I visit on a regular basis to work, but at the same time to clean out cookies from a site I visited once and never return.

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

this being a still applicable RFE, I don't think it should be autoresolved.

-> default owner

not going to do this in the backend; extension fodder. (this would be easy to do in an extension, now that we're about to have creation time stored for each cookie)