9943 - [PP]Preferences not being read for specific profiles

Status: VERIFIED FIXED

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

Description

[Grace Bush]

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:

Comment 1

[selmer (gone)]

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.

Comment 2

[Grace Bush]

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

Comment 3

[racham]

Let's wait for Grace's response before spending some time on this bug.

Comment 4

[Grace Bush]

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

Comment 5

[Jay Patel [:jay]]

Verified Invalid

Comment 6

[Grace Bush]

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

Comment 7

[leger]

Clearing Invalid resolution fue to reopen.

Comment 8

[selmer (gone)]

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.

Comment 9

[dbragg]

You're right Steve.  Marking assigned and leaving as M10 for now.  I need to
talk to Seth about a "pref lite" landing.

Comment 10

[dbragg]

Doesn't need to be done for M10 but must be done for beta.  Moving to M11.

Comment 11

[dbragg]

Fixed.  I'm calling the ResetPrefs function right before leaving the pref
migration component.

Comment 12

[Grace Bush]

build 19990924