I'm currently rewriting our cookie code, both backend and (hopefully) a few other changes here and there. So, an overview/update of the rewrite, as I see it now (all subject to change if anyone has advice): 1) I'm in the process of rewriting the entire backend, nsCookies, which also touches some other files. I think nsPermissions should also be involved in this, which Tim (riceman+bmo@mail.rit.edu) and also Michiel (mvl@shop-engine.nl, bug 179798) are working on. I suppose I'll coordinate with them to get everything together. 2) In terms of frontend, nsCookieService, I think some changes here might be really desirable, but I'm not sure yet. It depends on what magic can be worked with httpChannels. What we have now is pretty broken in terms of third party/mailnews cookie blocking. What I'm saying is that this may/may not warrant changes to the API. (Whether these changes can be made, since I believe the API is frozen, is another question.) 3) In terms of UI, I think there are one or two cookie features that we really should support (at the moment, cookie whitelisting, bug 184059), which will require some very minor UI changes (just a menu addition here, and a button addition there). People have been asking for this for ages (bug 75915), and it's pretty simple to implement. So far I've completed a lot of work on 1), should be ready "soon". I've implemented support for 3) in my new backend, but the UI changes should eventually go with it. 2) really depends on what the SR's think. Patches (and other dependent bugs) will be attached to this bug.

As a quick note, the cookie stuff (the "documentURI") already does not live on nsIHttpChannel. So I doubt that the frozen iface will be a problem, really...

per cathleen's comment in bug 143939: Yes, the risk involved in the rewrite is reasonably high; but the reward is high also - it will allow many long-sought-after features to be implemented, and will allow other neat things to be done with the UI (more on that later). My current plan is to land the rewrite in three stages (see bug 177698 for description of each): 1) has r+, pending sr=darin, bug 177698. 2) is finished on my end; waiting for stage 1 to be OK'ed before I pain reviewers with it. 3) is mostly refactoring after stage 2, won't take long ;) The permissions backend will also be receiving an overhaul courtesy of mvl, and should be ready by the time the above three stages are finished. UI redesign will have to wait for (a) the above to be completed, (b) any remaining issues to be thrashed out, (c) more pondering and collaboration with UI folk. I think there are some things that I might need your help with at some point: (a) Crafting of a cookie QA testsuite, to iron out any unforseen bugs. Should I talk to tever about this? (b) Making sure that reviews get done in time, depending on how much we're aiming for in 1.4 (i.e. if some UI work is to be done also, then we need to step up the pace and get some more active involvement from necessary parties). I'll chat to darin about this, I suppose. Basically, I can get the patches done fairly fast, so the bottleneck will be reviews (especially for the larger patches, which may require several iterations to get right).

Want to make sure you are aware of bug 185706, dealing with the transaction manager. It is something we are adding to enable profile data to be shared between multiple applications running a mozilla instance (like netscape and mozilla for instance). Currently we are targeting the preferences data to be shared, but cookies are another high priority and next on the list. If we can work that stuff (the transaction hook-up) into your re-write, or at least get you thinking about it ahead of time to make the adding of the transaction code easier down the road that would be awesome.

jgaunt: thanks for the heads-up. I think I'll need to chat to you about this - either by mail or irc, or in person, if it's important. I worry about this from the cookie and permissions perspective, because if it's not done right it could really open a can of worms. So I think we should start planning it now. (The bulk of the rewrite will be _finished_ by 1.4a, so if this is going to make 1.4...) And there will probably be restrictions on what versions can interoperate (both browsers will have to be 1.4+ based)...

Just making sure that you are aware of bug 86174 and bug 117222. See bug 86174 comment 17 for my proposal for dealing with session cookies.

how is this work progressing? i ask because it was brought up in bug 214431, which is looking for an option to accept session cookies without asking the user for permission. it was suggested that this bug is blocking other changes to cookie processing.

this work is, and will be, ongoing. it affects the cookie backend, not the cookie manager UI, and as such it should be (relatively) transparent to the user. this metabug is not relevant to bug 214431.

with the hashtable landing, i think we can safely say the backend rewrite is finished... time to fix this one :)