Closed Bug 67281 Opened 24 years ago Closed 21 years ago

Pref: networking.cookie.* should not be in network

Categories

(Core :: Networking: Cookies, defect)

defect
Not set
major

Tracking

()

VERIFIED WONTFIX

People

(Reporter: timeless, Assigned: darin.moz)

References

Details

(Keywords: arch, embed, topembed-)

Attachments

(4 files)

reason: they get timeless in trouble.
see #mozilla snipet:
[timeless] can anyone here blame me for putting network.cookie.* into a 
network.js file?
<jag> yes
conclusion:
[timeless]   then the cookies shouldn't be named network.*
<jag> I totally agree :-)
Blocks: 62755
i'll attach a patch that replaces network.cookie.* with cookie.*
Assignee: morse → timeless
Keywords: approval, arch, patch, review
Status: NEW → ASSIGNED
1. You also need to make the correction in the _elementIDs of 
pref-cookies.xul.

2. While you are doing this, you should also fix up the following two prefs.  
They are the image-manager equivalent of the two prefs you are fixing.

   network.image.imageBehavior
   network.image.warnAboutImages

If you make these two corrections, then r=morse
* proposing Mozilla0.9 as the target milestone
* adding embed keyword
Keywords: embed, mozilla0.9
Mozilla 0.8 builds started today. We would consider taking reviewed low risk 
fixes if they are available today (Wednesday, 7/Feb/01) or tomorrow (Thursday, 
8/Feb/01). Otherwise, please set the target milestone to Mozilla 0.9. Thanks.
morse: Could you have a look at this new patch, please?

timeless: hope you don't mind me taking this :-)

Gerv
Assignee: timeless → gervase.markham
Status: ASSIGNED → NEW
Target Milestone: --- → mozilla0.9.1
I'm confused by this patch for the following reasons:

1. Patch includes obsolete file
    xpfe/components/prefwindow/resources/content/Attic/pref-cookies.xul

2. Patch does not include the current version of that file
    extensions/cookie/resources/content/pref-cookies.xul

3. For images patch does include the correct file
    extensions/cookie/resources/content/pref-images.xul
   but it does not fix the occurence of "network" in var _elementIDs

1 and 2: My tree is out of date, it would seem.

3: I messed up.

I'll sort it :-)

Gerv
wouldn't cookie.behavior be better? [yes i do have this sitting in my tree, 
it's rotting w/ other cleanup]
That's not very clear... sadly, the pref is the wrong way round to call it
cookie.accept - how about cookie.reject ? 0 = Accept, 1 = NotForeign, 2=
RejectAll (I assume.)

Gerv
How about cookie.behavior.  It's not a boolean so why try to name it as if it 
were?
It just seems too vague. Changing cookie.cookieBehavior to cookie.behavior
doesn't seem like much of an improvement. How about cookie.rejectPolicy ? Or
cookie.acceptPolicy?

Gerv
On second thoughts, I don't care enough for it to keep this out of 0.9.1.
cookie.behavior (and image.behavior) it is.

Gerv
Attached patch Patch v.2Splinter Review
morse: Could you possibly have a look at this new attempt? Thanks :-)

Gerv
r=morse
Keywords: review
No sr= before tree close; unless morse disagrees and says this is important, I'm 
pushing it out to 0.9.2.

Gerv
Target Milestone: mozilla0.9.1 → mozilla0.9.2
You won't hear any disagreement from me.  Personally I think this is completely 
unimportant.
cookieBehavior : warnAboutCookies :: imageBehavior : imageWarnAboutImages ?

Oops -- shouldn't the last be named warnAboutImages?

/be
Discussion moved to n.p.m.18n and n.p.m.ui.

Gerv
r=morse for nit-picking fix.
so what do you do about users who already have these prefs set? the image
blocking thing is one thing, but the cookies thing is compeletely different - a
user could have been using an earlier version (or migrated from a Netscape 4.x 
browser) who had cookies disabled - suddenly they download 0.9.2 and their
browser is accepting cookies again, without them knowing it. 

I'm personally wondering if this should be WONTFIX.
If they were using a pre-release, that's their lookout. If they are upgrading 
from 4.x, I'm sure there's some pref name translating mechanism. If not, there 
should be. Who should I be seeing about profile migration issues?

We cannot say "once a pref name is established, it never changes" - that's a 
massive recipe for cruft in the prefs system. We are going to need some names to 
change at some point, particularly if we write an "advanced pref editor" which 
presents them in the form of a tree.

Hmm.

Gerv
you need to look in profile/pref-migrator and see how prefs are migrated from
4.x.. once you figure out what to add there, you need to land that change in
addition to the ones here.
I'm not going to get to this in the next 7 days.

Gerv
Target Milestone: mozilla0.9.2 → mozilla0.9.3
timeless: if this involves migration-fu, is it still worth doing?

Gerv
probably, besides you need to learn migration foo for bookmarks :-).
Well, then you'll need to point me at some docs or a knowledgeable person
because I can't make head or tail of it. I would have though there'd be a simple
text file: old name -> new name - but there doesn't seem to be.

Gerv
Doesn't look like this is getting fixed before the freeze tomorrow night.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
After seeing this again, I have second thoughts and am withdrawing my r= from 
these patches.

On the surface, this seems like a good thing to do for the sake of cleanliness.  
But it will break all existing user profiles.  Any user who upgrades his 6.01 
browser to 6.1 will lose all his saved cookie preferences.
timeless - feel free to WONTFIX this, or fix it with migration-fu.

Gerv
Assignee: gervase.markham → timeless
Target Milestone: mozilla0.9.4 → Future
now that cookies are headed to their new home in the necko module, I wonder if
this bug becomes invalid?
interesting point.
Assignee: timeless → timeless
Keywords: topembed
minusing for topembed. I supsect this is actually invalid.
Keywords: topembedtopembed-
Bug 62755 was just made topembed+, can we take a look at this one and see if it
still warrants to be made invalid or need a fix?  Making this one topembed+
since it blocks 62755 on paper.

recommend WONTFIX. Bug 210561 means this probably belongs wher it is.
Assignee: timeless → darin
QA Contact: tever → cookieqa
Summary: cookie pref names should not pollute network pref namespace → Pref: networking.cookie.* should not be in network
reopen this if you disagree, but this looks WONTFIX to me...
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Target Milestone: Future → ---
indeed, thanks bsmedberg!
V. Thanks.
Status: RESOLVED → VERIFIED
QA Contact: core.networking.cookies → benc
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: