Comment 0 for bug 548866

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.