Investigate use of the sticky flag on prefs

[nodiscc]

Followup to #415

I upgraded to Firefox 60 ESR on Debian today and saw the following changes in the debian-provided default firefox-esr.js file:

- ...
+// Default to classic view for about:newtab
+pref("browser.newtabpage.enhanced", false, sticky);

It would be good to determine how to use the sticky flag on prefs/what it does, and if it is useful and relevant to this project.

[nodiscc]

https://hg.mozilla.org/mozreview/gecko/rev/ec4ed3a0a8190164725d65d62c7b3e5272d32b68#index_header

Sticky prefs are already specifiable with sticky_pref

https://hg.mozilla.org/mozreview/gecko/rev/9b9384ee8abf22ed35fc6cff2ec0308b16fb3030#index_header

Convert sticky prefs in default pref files to the new syntax

-sticky_pref("lightweightThemes.selectedThemeID", "");
+pref("lightweightThemes.selectedThemeID", "", sticky);

https://hg.mozilla.org/mozilla-central/rev/99afe078d602

Bug 1098343 (part 1) - support 'sticky' preferences, meaning a user value is retained even when it matches the default. r=bsmedberg

instructions unclear

[pyllyukko]

https://hg.mozilla.org/mozilla-central/rev/99afe078d602

Also:

+        /* If new value is same as the default value and it's not a "sticky"
+           pref, then un-set the user value.

instructions unclear

Yep.

[nodiscc]

I'm no longer working on this.

[pyllyukko]

I'm no longer working on this.

Thanks for all your contributions during the years! ❤️

[nodiscc]

determine how to use the sticky flag on prefs/what it does, and if it is useful and relevant to this project.

During an unrelated search, I found this page: https://www.devdoc.net/web/developer.mozilla.org/en-US/docs/Preferences/A_brief_guide_to_Mozilla_preferences.html#Sticky_Preferences

Sticky preferences were introduced in Firefox 40 via bug 1098343.

Sticky preferences are created when they are defined using sticky_pref(). These preferences act as default preferences but whenever a value is created for the preference, that value is always written even when it matches the default. Sticky preferences are generally used for preferences that have a different default value in different channels with the intent being that once the user sets the preference in one channel, the preference will remain with that value when using a different channel with different defaults. For example, let's assume that Nightly has a preference "some.preference" which defaults to true while DeveloperEdition defaults the same preference to false and the user desires the preference to have the value true in both channels. If the preference is not a sticky preference and the user runs DeveloperEdition and flips the pref to true it will be saved as it is not the default. When the user then runs Nightly, the preference now has the same value as the default, so is not written by Nightly. When the user then runs DeveloperEdition again, the preference value will be false as no user preference was written by Nightly. If the preference is defined as a sticky preference, the value true will be written by Nightly even though it matches the current default, so when DeveloperEdition is run the preference keeps the desired value of true.

So I don't think it would be useful in the context of this user.js