Closed Bug 2596 Opened 26 years ago Closed 25 years ago

RFE: don't delete cookies file when disabling

Categories

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

x86
Windows 95
enhancement

Tracking

()

VERIFIED FIXED

People

(Reporter: paulmac, Assigned: paulmac)

Details

Currently the cookies.txt file gets deleted when you disable your cookies. An end-user has asked that we not delete the file. Here is the quote: "Sometimes we want to stop netscape from receiving NEW cookies temporarily but we want to keep the cookies that we already have. This is REALLY annoying to have to go and undelete the cookies.txt file from the hard drive."
Status: NEW → ASSIGNED
QA Contact: 3819
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
I have a problem understanding this report. We certainly don't delete the cookie file when cookies are disabled, at least not intentionally. So we would need to test to see if this file is getting deleted by accident. But there is no way to test this out since the preferences are not yet implemented in seamonkey. So that makes me wonder how the user who reported this ever disabled his cookies. I can only conclude that the user must have been confused and that this bug report is invalid. Closing it out as such. If I'm mistaken and someone actually has a test whereby they can demonstrate this bug, please re-open this report and include the test.
Status: RESOLVED → REOPENED
Assignee: morse → paulmac
Status: REOPENED → NEW
Status: NEW → ASSIGNED
this was filed as a bug in 4.5 code, and I transferred it over to bugzilla so the same thing would not happen with the 5.0 codebase. So, no it hasn't been confirmed with apprunner yet, but was put in as a placeholder with the assumption that the bug would 'carry over' to the 5.0 code. So I will re-open the bug, and assign it to me to check when the proper functionality is available, and then assign to you if it still happens...
Resolution: INVALID → ---
Target Milestone: M6
Target Milestone: M6 → M8
Status: ASSIGNED → RESOLVED
Closed: 26 years ago25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.