Hi there.
So the changes have been lived for a couple of weeks now and some issues
were raised or encountered since. So I would like to clarify some of those.
1- If you define a StaticPref in StaticPrefList.h there is absolutely
no-need to also defines the value in all.js. In fact this is strongly
discouraged and there should almost never be a need for it. There will
be no end-user visible difference if your pref is only defined in
StaticPrefList.h : the pref value will still appear in about:config.
Since Nick Nethercote cleaned up all.js in his first StaticPref
iteration; 403 preferences have popped up with duplicated
initialisation, often with different default value set between the two.
So if you add a StaticPref, remove the existing all.js entry if it exists.
2- Please read the StaticPrefList.h documentation present at the
beginning of the file. Please keep its content organised within the
right section and alphabetically ordered. Don't group preferences with
different prefix together because they relate to the same topic.
Reconside the prefix used instead.
3- Carefully consider when a StaticPref is defined with a Once policy:
do you need to use such policy and are you appropriately testing it?
StaticPrefs with a Once policy will be initialised when one is read; all
of them will now be frozen for the entire lifetime of the parent process
(following bug 1554334)
If you create a test for that pref, and set that pref via means such as
SpecialPower.pushPref(), via the web-platform-test etc; those will *not*
update the value of the StaticPref. In order to prevent such misuse, in
bug 1556131 at the request of Boris we created a test that is enabled
during automation testing on debug build. Should anything attempts to
modify the underlying preference of a `Once` StaticPref, it will crash
with something like:
Assertion failure: staticPrefValue == preferenceValue (Preference
'webgl.force-layers-readback' got modified since
StaticPrefs::WebGLForceLayersReadback got initialized. Consider using a
Live StaticPrefs instead), at
/builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/StaticPrefList.h:6529
All the best
Jean-Yves
On 15/05/2019 11:02 pm, Jean-Yves Avenard wrote:
Dear all.
/TLDR; Wherever you used to use gfxPrefs, soon you will have to use
StaticPrefs./
In a couple of days, once /Bug 1550422
<https://bugzilla.mozilla.org/show_bug.cgi?id=1550422>//lands I will
be retiring gfxPrefs. All features originally found in gfxPrefs are
now available in StaticPrefs with some extra bonuses./
//For the background, StaticPrefs gives you the ability to access a
preference via a thread-safe accessor.
//
/StaticPrefs and Preferences will now be available on all processes
(not just main and content, this includes GPU, VR and RDD process)/
//
/3 levels of update policies: Skip, Once and Live:/
/* Skip policy will ignore all user overrides.
* Once will read the preference once and will never be updated again
* Live is the original behaviour, the values will be updated across
all processes whenever the preference change.
/
/Possibility to dynamically set a StaticPref on any threads (however,
the changes aren't propagated to other processes; doing otherwise is
certainly doable, I'm not convinced of the use case however)./
/There are few more options, to know more I invite you to read the
StaticPrefList.h file
/
/The desire to gfxPrefs came from yet another misuse of StaticPrefs in
the GPU process. In addition gfxPrefs turned out to not be thread-safe./
/It became rather tiring to always juggle between gfxPrefs and
StaticPrefs depending on which process the code could run./
/And as Mr MacLeod used to say: There can be only one/
/Jean-Yves
/
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
