Closed Bug 157922 Opened 22 years ago Closed 22 years ago

Profile information (prefs.js) being stored in wrong profile folder

Categories

(Core Graveyard :: QuickLaunch (AKA turbo mode), defect)

x86
Windows ME
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: agracebush, Assigned: law)

Details

(Whiteboard: [adt2])

Found while testing 'losing prefs.js' bug 155080 and doing set up for another test 1. Clean Mozilla (all profiles) 2. Create new profile- verify QL is on 3. creat mail/bookmark/activation check prefs file after close 4. launch second time from start/program/app/profilemanager 5. delete profile 1 (do not delete files) 6. create profile 2 - different activation, bookmark 7. when trying to create mail- mail from profile 1 displays :( 8. view profile dirs via explorer....data being written to profile 1 (.slt) dir view prefs....new activation data written to the file, old mail settings there- in wrong directory 9. close/relaunch- profile 2 has empty prefs file! 10. repeat steps 5-9 this time delete profile files makes no difference- profile 3 uses profile 2 data and second launch shows no prefs for that profile (7/16 build on WinME)
add to cc list marking critical nominating
Severity: normal → critical
Keywords: nsbeta1
OS: other → Windows ME
This did not occur when I created new profile -without deleting other profile-new settings were saved in proper directory. If QL is on, and I try to delete the single profile being used (whether I choose to save files or not), that directory remains open to the app. If you try to delete the profile from explorer, you are warned files are in use.
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2]
not seeing this on mozilla nightly- 1/13 ( and after prefs bug fixed a while back) marking wfm
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
verified
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.