Closed Bug 225790 Opened 20 years ago Closed 20 years ago
Tools - Options - Privacy setting changes are forgotten (but about:config works)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031114 Firebird/0.7+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031114 Firebird/0.7+ Example : try to change the cache size using the UI (Tools - Options - Privacy - Cache), from 50000 to let's say 8192. You click on OK, quit the dialog. Then you access the same section again (UI) : the old settings are back ! However, if you change browser.cache.disk.capacity using about:config , the change is accepted. That is, it persists between sessions *and* the options UI displays it ! Gotcha, UI :-) Note : it could of course be linked to http://bugzilla.mozilla.org/show_bug.cgi?id=225239 . Reproducible: Always Steps to Reproduce: 1. Create a new profile 2. Change the cache size using the UI (Tools - Options - Privacy - Cache), from 50000 to let's say 8192. You click on OK, quit the dialog. 3. Access the same section again (UI) Actual Results: The old settings are back ! Expected Results: Do I really have to tell ? ;-) However, if you change browser.cache.disk.capacity using "about:config", the change is accepted. That is, it persists between sessions *and* the options UI displays it ! Gotcha, UI :-) Note : it could of course be linked to http://bugzilla.mozilla.org/show_bug.cgi?id=225239 .
(Sorry for the repetition: user deficiency in using copy/paste :-o )
Would this happen to be an installer build? Or a zipped one?
It's an installer build. I'll uninstall the installer build version, and try (again with a new profile) : - the zipped build of the same FTP directory - the latest installer build (mentioning the version) - the latest zipped build (mentioning the version) Then I'll report. Just wait a moment ... (living in GMT+1)
I'm pretty sure this duplicates another bug about problems with Tools/Options/Privacy in the installer build. If you find this issue in a zip build, I would reopen this bug. *** This bug has been marked as a duplicate of 225698 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Indeed : the zipped build works, the installer one (from the same directory, still the latest one) does not. The bug summary can now be more precise. For each test I erased all of my old profile, even %APPDATA%\Phoenix (with the registry), and immediately did a "-p" to recreate a profile just after installation/extraction. Then I went in the Options UI to check. Note 1 : I did a custom installation (adding the only thing I could click on : the development tools), choosing another installation directory. Note 2 : I didn't choose the default directory for my profiles, meaning that the Profile directory was *not* located under the "Phoenix" registry directory. Well there's one, but empty and useless. Note 3 : I'm using Windows XP Pro SP1. I'm ready for other tests if you want.
Oh yes. A duplicate. Sorry for the wasted time.
Status: RESOLVED → VERIFIED
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
You need to log in before you can comment on or make changes to this bug.