User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040702 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040702 In the preferences "Cookie Lifetime Policy" section, "Accept for current session only" and "Ask for each cookie" are presently mutually exclusive. They should not be and they didn't used to be. Users should be able to be asked about each cookie and then upon closing the browser have all of those cookies automatically disappear. Reproducible: Always Steps to Reproduce:

Ah, I now see that the revised "ask" dialog box allows one to choose the given cookie to be permitted for the current session only. But, there's still a problem... When I have the lifetime policy set to "Ask for each cookie," cookies from sites that are already in my Cookie Manager whitelist will persist after the browser is closed.

I'm marking this bug invalid and opening Bug 263268 which I hope better describes the situation.

Re-opening and moving to Core. These two preferences should not be mutually exclusive, regardless of the front-end UI. Users should be able to be asked each time a site asks to set a cookie, in addition to having the option to set all cookies as session cookies. Our current network.cookie.lifetimePolicy allows me to get asked each time, OR have all cookies expire on quit, but not both. IMO, this should be broken into two separate prefs. Keep the existing lifetime policy pref, possibly rearranging it. A new Boolean pref should be added, something like network.cookie.askBeforeAccepting, which will allow the Allow/Deny prompt to be displayed each time a site tries to set a cookie. cl

Its not really invalid, but it is WONTFIX. The dialog's choice is explicit, and should be respected. The choice given on prompt is "Accept", "Accept for Sesssion" and "Block" ergo the only possible effect that the session-only setting could have would be to make "Accept" behave the same way as "Accept for Session" which seems a tad silly (and unexpected). The only point in separating them would be to drop the Accept button and not allow the user the choice of permanently accepting a cookie, but I don't see the usefulness of that.

(In reply to comment #4) > The only point in separating them would be to drop the Accept > button and not allow the user the choice of permanently accepting a cookie, but > I don't see the usefulness of that. What about a site whose cookies you don't want to allow, period? If I set "force all cookies to be session cookies" but I still don't want to allow, say, doubleclick.net to set a cookie EVER, there's no UI for doing this from scratch. (Yes, I'm aware that there are client workarounds for this particular example, but most of them are pretty ugly and require a knowledge that a site is going to try to set cookies in advance.) Just wanted to point out a counter-example. I realise this is a pretty low priority but I figured since I was WONTFIXing bug 174070 I should probably comment here on why I think this bug should have been fixed. cl

In my opinion, whether or not to accept a cookie is prior to the consideration of its lifetime. To me, lifetime is a setting that only applies to accepted cookies. With that in mind, it seems the only logical settings for lifetimePolicy would be 0 (default): Use supplied lifetime 1: Accept for session only 2: Cookies last for the number of days specified in network.cookie.lifetime.days I understand the point you're making about consistency/redundancy, but that goes away if you pull the option to Ask out of the lifetimePolicy options. Each browser could extend the Exceptions UI to have one of 4 values for each site Accept Accept for session Accept for N days Deny The Ask dialog could have just Accept/Deny+remember. If remember is checked then the specified lifetimePolicy will read to see what to add the site to the Exceptions list as. Users can go into the Exceptions list and change the setting on a per site basis, the UI stays clean and consistent.