Hi.
Thanks for the kind words.
> On 11 Jun 2019, at 9:49 pm, Kartikaya Gupta <kgu...@mozilla.com> wrote:
>
> IIRC another difference between prefs in all.js and gfxPrefs was that if a
> pref was not listed in all.js, you couldn't use it in the
> {test-,ref-,}pref(...) annotations in reftest.list files. Can you confirm
> that listing the pref in StaticPrefs but not all.js is not subject to this
> restriction?
A gfxPref didn't set or create the related Preference to any value. It was only
happening the other way round: the gfxPref would be initialised in that process
to the value of the Preference at the time of the process creation but only if
the preference existed.
Such that the value set in all.js would override the gfxPrefs default.
If you had only defined the gfxPref then the pref wouldn't show up in
about:config either (which is why people for convenience also added an entry to
all.js).
However, if you were to call the gfxPref setter method, it would then set the
related Preference but only if called on the parent process and in the main
thread. Otherwise, the change to the gfxPref was local to the current process
only.
Setting a pref by listing all.js or in StaticPrefList.h initialise things in
the same manner, they are fundamentally equivalent.
Now, while I'm not aware of the case you describe, I don't see how using
StaticPref could break that.
I hope that none of the gfxpref flaws got carried into StaticPref, I believe
they were all fixed following this transition.
Jean-Yves
Get Firefox for iOS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
