This bug is due to the fact, applications are restarted before extension
defaults are loaded.
To reproduce, choose any preference and set the values like:
system default:
pref("prefkey",systemvalue);
extension default:
pref("prefkey", extensiondefault);
user pref:
user_pref("prefkey", systemvalue);
Next, trigger application behaviour similar to upgrade by removing compreg.dat
from profile and start the application.
Result:
User sees extensiondefault after upgrade, because the user_pref has been
eliminated ... which is definitly not what the user expects because he explicitly
had *systemvalue* set before the upgrade.
Evaluation:
The bug happens because restart is performed *before* extension defaults have been
loaded and the prefapi.cpp always eliminate user preference if the user preference
is equal to the actual default (which happens to be extensiondefault normally - so
no reset, but is systemvalue during restart).
Proposed Fix:
1. savePrefs should not try to be smart ... this patch removes the heuristic that guesses
whether a setting can be eliminated or not; it should be sufficient to only eliminate
prefs in hashPrefs.
2. This patch prevents hashPrefs from eliminating the user pref in case we are in
*startup* ... unfortunately no such state info exists, which lets us guess that
we are in startup for the previously not dealt case: !set_default &&
!pref_ValueChanged(pref->defaultPref, value, type) && !PREF_HAS_USER_VALUE(pref).
If this is the case we explicitly remember that this setting is a user-pref ...
even though it might be temporarily equal to the default pref.
This bug is due to the fact, applications are restarted before extension
defaults are loaded.
To reproduce, choose any preference and set the values like: "prefkey" ,systemvalue) ; pref("prefkey" , systemvalue);
system default:
pref(
extension default:
pref("prefkey", extensiondefault);
user pref:
user_
Next, trigger application behaviour similar to upgrade by removing compreg.dat
from profile and start the application.
Result:
User sees extensiondefault after upgrade, because the user_pref has been
eliminated ... which is definitly not what the user expects because he explicitly
had *systemvalue* set before the upgrade.
Evaluation:
The bug happens because restart is performed *before* extension defaults have been
loaded and the prefapi.cpp always eliminate user preference if the user preference
is equal to the actual default (which happens to be extensiondefault normally - so
no reset, but is systemvalue during restart).
Proposed Fix:
1. savePrefs should not try to be smart ... this patch removes the heuristic that guesses
whether a setting can be eliminated or not; it should be sufficient to only eliminate
prefs in hashPrefs.
2. This patch prevents hashPrefs from eliminating the user pref in case we are in ged(pref- >defaultPref, value, type) && !PREF_HAS_ USER_VALUE( pref).
*startup* ... unfortunately no such state info exists, which lets us guess that
we are in startup for the previously not dealt case: !set_default &&
!pref_ValueChan
If this is the case we explicitly remember that this setting is a user-pref ...
even though it might be temporarily equal to the default pref.