Closed Bug 9943 Opened 25 years ago Closed 25 years ago

[PP]Preferences not being read for specific profiles

Categories

(Core Graveyard :: Profile: Migration, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: agracebush, Assigned: dbragg)

References

Details

Steps to Reproduce 1)Install build for 19990715- do not delete registry (testing profiles/profile data is maintained across builds) 2)Edit/prefs to verify which profile using (previous 5.0 profile created/profile migrated from 4.x) Actual Results: Preferences are defaults or blank Expected Results: Some preferences appearance, mail/news identity would be verifiable Build Date & Platform Bug Found: build for 19990715 (note build date on apprunner is incorrect - see bug 9902) Additional Builds and Platforms Tested On: Linux build for 19990715 is ok, Mac is not launching - (see bug 9928) Steve, Do you know where this should be assigned? Don't see anything in component list that is pertinent? Thanks, Grace Additional Information:
Assignee: chofmann → racham
Let's start off assuming this is a profiles bug. Bhuvan, please see if we can reproduce this on a current build and figure out if profile manager has behaved properly.
QA Contact: leger → gbush
adding myself as QA contact Bhuvan, I have tried this again (more than once) and cannot reproduce...let me try some more before taking time with it...the prefs50.js files looked much different when I reported this than what I am getting now. Let me investigate and I will let you know. Grace
Status: NEW → ASSIGNED
Target Milestone: M9
Let's wait for Grace's response before spending some time on this bug.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
I repeated testing builds for past 3 days and cannot reproduce. What occurred yesterday may have resulted from other testing (removing nsreg for clean install testing and patch jar testing) Upgrades and new installs seem to be carrying old profiles and preferences forward, marking invalid
Status: RESOLVED → VERIFIED
Verified Invalid
Status: VERIFIED → REOPENED
Component: other → Profile Migration
I repeated this bug today and now can reproduce at will on both NT and Win98. I found when testing the 3 scenarios for profile migration (0 4.x profiles, 1 4.x profile, many 4.x profiles) This occurred with 1 and many-obviously without profile migration, 5.0 profile does not get written over, corrupted Steps to reproduce: 1. Delete mozregistry.dat 2. Run apprunner -installer 3. Create one new profile in Profile Manager At same time, migrate one of the existing 4.x profiles 4. Choose the new 5.0 profile and start apprunner 5. Edit/prefs and see 4.x profile data - there should be no preferences at this point-new profile Actual results: New 5.0 prefs had data matching data migrated from 4.x profile Expected results: Empty/default prefs50.js allowing for entering new data Platforms tested: Win98 (1 4.x profile) NT (many 4.x profiles) Did not occur on WIn95 (no 4.x profiles) nor Mac/Linux without migration capability yet
Resolution: INVALID → ---
Clearing Invalid resolution fue to reopen.
Assignee: racham → dbragg
Status: REOPENED → NEW
Target Milestone: M9 → M10
Don, this looks like a symptom of the init_pref() stuff we've been talking about. I'm marking this TFV = M10 to get it off of Chofmann's radar, you should set the real value if it's different.
Status: NEW → ASSIGNED
You're right Steve. Marking assigned and leaving as M10 for now. I need to talk to Seth about a "pref lite" landing.
Blocks: 11218
Target Milestone: M10 → M11
Doesn't need to be done for M10 but must be done for beta. Moving to M11.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Fixed. I'm calling the ResetPrefs function right before leaving the pref migration component.
Status: RESOLVED → VERIFIED
build 19990924
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.