Closed Bug 23628 Opened 25 years ago Closed 25 years ago

navigator.cookieEnabled is true even is cookies are diabled

Categories

(Core :: Networking: Cookies, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: bugzilla, Assigned: matt)

References

Details

If you go into the preferences and set cookies to "disable cookies" and then check for navigator.cookieEnabled is still true. In fact the navigator.cookieEnabled is *ALWAYS* true. Build 2000011008
Assignee: morse → matt
WOW, speak about regressions -- this one is really bad. Looks like the pref panel has been completely redesigned and is full of bugs. First a correction. The reporter mentions "navigator.cookieEnabled". The actual designation for this pref is network.cookie.cookieBehavior". Here are all the problems (regressions) that I see in it. 1. Go to edit/preferenced/advanced/cookies. Panel of cookie preferences appears but there is no initial selection in the radio button for the cookie behavior of accept-all/accept-only-domestic/disable. 2. Select "accept-all" and close the prefs panel with OK. Nothing gets written into prefs.js. This is a change in the old behavior but can be argued as not being a bug. But that means that if the browser now crashes, the changed pref will not be saved. 3. Exit browser. The prefs.js file now contains a pref named network.cookie.cookieBehaviour. Note the British spelling ("iou") instead of the American spelling ("io"). This means that if there was a previous prefs.js file, it would have contained the pref with the American spelling and now we have the pref appearing twice in the file. 3. The value of this "iou" pref is 0 in the file. It used to have a value of 1 for accept-all when it was "io". This is not necessarily a bug unless the value is being interpreted incorrectly as I'm sure it will be by the cookie module. Worse yet, the cookie module will probably never even see the "iou" pref because of the mis-spelling -- it is probably still looking for the "io" pref. Which would explain why changing the preference in the preference panel is having no effect on the way the browser actually handles cookies. 4. The cookie-pref panel now has a new button labelled "view stored cookies" which brings up the cookie viewer. Great idea except that the viewer is coming up much too large. So large in fact that the OK/Cancel buttons at the bottom of the screen are not even visible. Same comment applies to the wallet viewer and signon viewer that are now accessible from the advanced/wallet preference panel -- they too are much too big. I think the change to the new preference layout is great -- I just wish we hadn't introduced so many regressions by doing so. In any case, preferences are in matt's area, not mine, so I'm reassigning the bug.
Oops -- looks like I have two items numbered 3 in my list above. Consider them renumbered sequentially so that they are 1 through 5 for any future reference to them.
This bug is important for the M13 freeze but it hasn't even been looked at yet. Wondering if I assigned it to the wrong person. Copying Goodger on it in case its something that he wants to fix.
Depends on: 24129
I just pulled a fresh tree and checked out these problems again. Looks like some if not all of them might be fixed. But its hard to say for sure because all of this is now being masked by a much more serious bug, namely bug 24129.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Now that 24129 has been partially fixed, I was able to check this out more thoroughly. Everything here appears to be fixed except for item 2 (writing out new prefs immediately). But this was probably an intentional change and not a bug. Closing this out now as works-for-me.
Keywords: verifyme
It works fine... Verified!
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.