We're starting to run into problems with the 50 limit being too low. The Chrome guys agree that we should raise it to 150.
This should block 2.0, since it's a problem now, and we want behavior to be consistent between browsers.
Created attachment 469266 [details] [diff] [review] patch
We should consider landing this on the older branches as well if we're going to change it. If sites expand into the new limits that will start on a particular calendar date and extend into the future, not be based on what version the user happens to be running.
Only to versions that have the soft global limit though. When did that land?
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/af278cec894d 7/20/09 on 1.9.2. Agree we should land there too.
To be clear, for anyone reading along: the reason the limit is too low is that, when we changed the limit to mean "per base domain" instead of "per host", we caused trouble for sites that rely on being able to set a bunch of cookies on different subdomains. Like Google. We still want the limit, but it's not as important now that we have our new purging algorithm -- we've prevented the kind of attack where a malicious site can log you out of everything; the worst you can do is cause the browser to take up a bunch of memory and disk.
Comment on attachment 469266 [details] [diff] [review] patch > // default limits for the cookie list. these can be tuned by the > // network.cookie.maxNumber and network.cookie.maxPerHost prefs respectively. Is this comment still correct? We have four defaults here. r=sdwilsh
Comment on attachment 469266 [details] [diff] [review] patch Looking for approval -- we want branch to be consistent with trunk here, so behavior is uniform.
(In reply to comment #7) > Is this comment still correct? We have four defaults here. Yeah, it's correct; I could mention the purgeAge pref too, though.
http://hg.mozilla.org/mozilla-central/rev/a02aee4f7197 Still need a branch landing here.
Landed on 1.9.2. http://hg.mozilla.org/releases/mozilla-1.9.2/rev/d49e8022e892