Closed Bug 7436 Opened 25 years ago Closed 25 years ago

[BLOCK] ProfMgr needs prefs->Startup() and prefs->ReadUserPrefs() to be separated.

Categories

(Core :: Preferences: Backend, defect, P1)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: racham, Assigned: mcmullen)

References

Details

(Whiteboard: I have this in my tree, but with many related changes to check in.)

In order to start communicator by switching a profile from Profile Manager,
profile services require a method that allows all hashed prefs to be forgotten.
Erasing all the hashed prefs until that would allow prefs/profiles to point at
the newly selected profile. Profiles should be able to call ForgetUserPrefs when
it switches the profiles and hence is the requirement for this method in
nsIPrefs. Opened this bug as a reminder for the implementation of that
interface.
Would this new routine also be responsible for all the pref-changed callbacks?
Status: NEW → ASSIGNED
Steve, when this routine is called, all userprefs will be restored to their
default values.

Registered callbacks should occcur, I think. Or perhaps we can provide a boolean
parameter for this.

The prefs file should not be written out, however, when this call occurs.
OS: Windows NT → All
Hardware: PC → All
Target Milestone: M7
Changing platform/OS to "All". Target is M7
After discussing this with John, here's the new plan:

1. prefs startup will no longer load any user prefs
2. application is now responsible for indicating user prefs to load by calling a
new interface in prefs
3. prefs code to be slightly re-arranged to ensure all entry points validate
structures, to make startup only load default prefs, to create new entry point
4. apprunner to be changed to call new entry point after profile is known
5. viewer to be changed to call new entry point with CWD to preserve current
behavior

This allows us to do the minimal computation for the correct result and
satisfies all requirements (I hope.)
One thing about your summary that does not agree with my recollection (or
opinion): the new interface should NOT specify any directory. The new interface
should simply be ReadUserPrefs() (no parameters). To the extent possible, callers
of the prefs interface should not be required to make decisions about where the
prefs file is. That's the prefs manager's business.

So viewer should not be passing in CWD, and the main() of apprunner will not be
trying to compute the correct prefs file. That logic is all in prefs, and should
remain there.
Hmmm.  How was viewer going to inform you to use CWD while apprunner would use
the actual profile information?  Perhaps passing in a symbolic argument rather
than the directory's nsFileSpec?  (e.g. USE_PROFMGR=true/false)  If so, this
could be a parameter to the startup routine.  Let me know how you thought this
should actually work.
There was no difference in viewer before, and there need be none now. There is no
need to pass in any parameters before, and there is none now.

The decision to use the CWD is (and will remain) based on an internal decision of
the prefs manager. This happens only if the file locator service is not available
(which happens to be the case in viewer and perhaps some other embedding apps).
If the file locator service is available, it can tell the prefs manager which
file to open.

This decision and the information supporting it are not the business of clients
of libpref. They weren't before, and they should not become so now.

Why is this controversial? We discussed factoring the code internally. From
callers' points of view, Startup() is being replaced by two successive calls to
Startup() and ReadUserPrefs(). Neither call needs any parameters. I don't want
any re-engineering of the API apart from that.
It's not controversial, I'm just being slow in understanding how the file
locator works because I don't know how it's connected to profile manager's
presence.

Given your last comments, then I modify my previous statements 4 & 5 as simply
"viewer and apprunner call ReadUserPrefs() in the right place and everything
else just works."

Sorry for the obtusion.
Ahh, the sheer bliss of it all... :-)
By the way, I may still have time to do this!
Blocks: 7579
Severity: normal → blocker
Priority: P3 → P1
John says that this is blocking the profile folks.
Summary: ProfMgr needs implementation of ForgetUserPrefs() method → [BLOCK] ProfMgr needs implementation of ForgetUserPrefs() method
Summary: [BLOCK] ProfMgr needs implementation of ForgetUserPrefs() method → [BLOCK] ProfMgr needs prefs->Startup() and prefs->ReadUserPrefs() to be separated.
Whiteboard: I have this in my tree, but with many related changes to check in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This is now checked in.
Is there a way to verify this thru running the profile manager yet? Or just mark
this verified as some code that needed to be written to allow some more code to
be written...
Well, to test this, you should be able to:

1. Create your first profile and set some distinctive preferences.
2. Launch again with the command-line option set to -ProfileWizard. When the
profile wizard appears, create a second profile.
3. Verify that the preference you set in the first profile is not showing up in
the second profile. Set another different distinctive preference, and quit.
4. Relaunch, and notice that the profile picker appears. You can launch with
either profile now.
5. The preferences specific to one profile should never show up in the second
profile.
Status: RESOLVED → VERIFIED
Thanks, John.
I verified, with the 6/19 builds, that you can create and run two distinct
profiles and that their preferences are kept separate.
Moving all libPref component bugs to new Preferences: Backend component.  
libPref component will be deleted.
Component: libPref → Preferences: Backend
You need to log in before you can comment on or make changes to this bug.