187304 - Backend rewrite of cookies

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect)

Description

[[e-mail]]

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 ([e-mail]) and also Michiel ([e-mail], 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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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...

Comment 2

[[e-mail]]

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).

Comment 3

[John Gaunt (redfive)]

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.

Comment 4

[[e-mail]]

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)...

Comment 5

[Vaclav Dvorak]

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.

Comment 6

[Michael Newton]

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.

Comment 7

[[e-mail]]

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.

Comment 8

[[e-mail]]

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