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)
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
Reporter | ||
Comment 1•25 years ago
|
||
Updated•25 years ago
|
Assignee: morse → matt
Comment 2•25 years ago
|
||
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.
Comment 3•25 years ago
|
||
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.
Comment 4•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
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.
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Comment 6•25 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•