Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090616 Firefox/3.5 ID:20090616212246 After a major upgrade from 3.0 users who have set to clear passwords in the CRH dialog will not be able to revert this setting. The CRH dialog always clears the passwords. We had the same problem on shutdown which was solved in bug 497656 but that patch didn't fix problem in the CRH dialog run during a session. Slightly modified STR form bug 497656: 1. Open about:config 2. Flip "privacy.cpd.passwords" to 'true' 3. Visit URL (or any login page) 4. Type in username and password (at URL, username='foo' password='bar') 5. Click "Remember" in notification-bar, to save password 6. Inspect saved passwords in Prefs / Security / Saved Passwords. 7. Ctrl-Shift-Delete to bring up "Clear Recent History" 8. Uncheck all boxes -- so, nothing should be cleared. 9. Press "Clear Now" 10. Inspect again saved passwords in Prefs / Security / Saved Passwords. With step 9 all saved passwords will be removed from the profile. There is no way to stop this action via the UI. Users would have to enter about:config to reset this preference. As said this only happens when running CRH from within the tools menu. The passwords are not getting cleared on shutdown.
Summary: CRH dialog always clears passwords after a MU from Firefox 3.0.0.x (settings cannot be undone) → CRH dialog called via Tools always clears passwords/offline website data after a MU from Firefox 3.0.0.x (settings cannot be undone via UI)
(In reply to comment #0) > Slightly modified STR form bug 497656: > 1. Open about:config > 2. Flip "privacy.cpd.passwords" to 'true' This pref doesn't exist in Firefox 3.0, so how is it getting set before the MU? Seems to me like this bug doesn't match any realistic scenario (requires using about:config to flip a pref), so that would make it INVALID.
After talking with Gavin on IRC we discovered that an accidentally run of Firefox 3.5 beta 99 in between caused this problem for me. Starting Firefox 3.5 RC2 directly after running Firefox 126.96.36.199 doesn't show this problem because we import the prefs correctly now. Sorry for this false alert but it shows once again that you always should use the latest versions for verifications. :/
No longer blocks: 497656
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.