109015 - -P <profilename> option to bypass the profile picker will not update XUL/or read prefs settings on load

Status: VERIFIED DUPLICATE of bug 108383

(Core Graveyard :: Profile: BackEnd, defect)

Description

[[not reading bugmail]]

Mozilla and ns6.2 will read the prefs file if you do a
manual selection from the desktop shortcut just fine, settings will stick.  The
problem lies in the commandline option for -P <profilename> to bypass the
profile picker.  This will not read the settings from the file.. and -P
<profilename> was broken last week and someone checked in a change for it.  So
prefs stick upon manual profile selection, not -P option.  :)



adding critical severity, could also be major.. its data loss if you count it
doesn't use the pref file settings.. and major if loss of functionality..

Comment 1

[[not reading bugmail]]

if you run the -P <profilename> option after you use the manual profile picker
to edit preference settings.. it will load those new settings.. so maybe this is
a reverse senario.. where it will not write prefs to disk after using -P
<profilename> .. hmm.  Dont know which it is, cant test that.

Comment 2

[[not reading bugmail]]

ok, the if I am using the -P option and I go to pref panel and deselect the 'go'
checkbox.. XUL will not update the screen after 'ok' is done.  On reloading
mozilla using -P option XUL will still not be updated.. but if I reload mozilla
using the profile picker, the XUL 'go' button will be hidden to reflect the
settings in pref panel.

Comment 3

[[not reading bugmail]]

so its a load issue, and see also bug 108198 for bogus prefs settings.

Comment 4

[[not reading bugmail]]

adding keyword dataloss, changing summary.

Comment 5

[Gilles Durys]

*** This bug has been marked as a duplicate of 108383 ***

Comment 6

[K'Trina Medina]

Verified as a dupe of 108383