On Fri, Mar 22, 2019 at 10:41 AM Thomas Eugene Bishop <
thomasbishop(a)wenlin.com> wrote:
(3) If DefaultUserOptions and onGetPreferences both
specify default
values, and they differ, onGetPreferences wins. I believe this scenario
should be avoided. Having an option whose default is “X” before you go to
the Preferences form, but changes to “Y” when you do go there, could give
the user the false impression that the value has been “Y” all along, and
lead to confusion and instability.
It probably also means that when you go to your preferences for some
unrelated reason and press save, that setting will change, even if you
never interacted with the field. Definitely not great. (Although this is
being abused for beta feature automatic rollout (T64815) so it's a feature,
sort of.)
(4) If DefaultUserOptions and $wgDefaultUserOptions both specify default
values, and they differ, $wgDefaultUserOptions wins.
That is by design, DefaultUserOptions is just a mechanism to set
$wgDefaultUserOptions.
A default is NOT required there. If there’s a default
in onGetPreferences
but not in DefaultUserOptions, there’s a bug per (1) above. If a default in
onGetPreferences agrees with DefaultUserOptions, it’s redundant per (2)
above. If it disagrees, there’s a bug per (3) above.
Also having a 'default' key but not DefaultUserOptions can be actively
harmful (or at least that used to be the case in the past), see T64946.