Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On 6/11/19 7:49 AM, Kartikaya Gupta 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. That restriction is due to the code at https://searchfox.org

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

Hi. Thanks for the kind words. > On 11 Jun 2019, at 9:49 pm, Kartikaya Gupta 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 co

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On Tue., Jun. 11, 2019, 04:01 Jean-Yves Avenard, wrote: > > 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 visib

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

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 str

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On 16/05/2019 9:02 am, Botond Ballo wrote: Will SpecialPowers.pushPrefEnv(), which currently does propagate the prefs at least between the content and parent processes, continue to work? A lot of tests rely on this. Yes of course. The changes was to add changes so that process other than the

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On Wed, May 15, 2019 at 07:02:58PM -0400, Botond Ballo wrote: On Wed, May 15, 2019 at 6:54 PM Jean-Yves Avenard wrote: It is then up to each process to handle preference modifications and pass that change. There's no automatic or universal method on how this is done unfortunately. Will Specia

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On Wed, May 15, 2019 at 6:54 PM Jean-Yves Avenard wrote: > It is then up to each process to handle preference modifications and > pass that change. There's no automatic or universal method on how this > is done unfortunately. Will SpecialPowers.pushPrefEnv(), which currently does propagate the pr

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

Hi On 16/05/2019 1:54 am, Nicholas Alexander wrote: Forgive my rank ignorance here, but as an outsider this surprises me: I expect "Gecko preferences" to be (eventually) consistent across processes.  Is this just not the case, and it's common for prefs to vary between the main and content/gfx

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

On Wed, May 15, 2019 at 6:03 AM Jean-Yves Avenard wrote: > Dear all. > > /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)./ > Forgive my

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

Great to see this consolidation happening; it's going to be a great improvement on the current situation. Just to check, would it be correct to assume this won't be landing on central until after the current Fx68 soft-freeze period? It seems like the sort of wide-ranging change that probably s

Change to preferences via StaticPrefs, tremoval of gfxPrefs

Dear all. /TLDR; Wherever you used to use gfxPrefs, soon you will have to use StaticPrefs./ In a couple of days, once /Bug 1550422 //lands I will be retiring gfxPrefs. All features originally found in gfxPrefs are now available in Static