Yeah, I wrote the script so it reads files from that subfolder because I wanted to avoid using files and folders that we know Firefox uses/used, to avoid potential conflicts.

Caveats from 3.3...

The user.js has some one-char switches for sections to make it easy to turn the entire section on or off (eg deprecated items by ESR version). Unfortunately, the script cannot detect any changes with these, and therefore does not reapply them if they differ.

I might be misunderstanding something, but I think that sounds potentially confusing/misleading. The script treats inactive preferences within multi-line comments differently depending on the mode of operation (append or merge). Are those the ones we're talking about?

The default mode appends all lines indiscriminately, meaning that inactive preferences in user.js will be made active (turned on) when there are active overrides for those preferences in user-overrides.js, and active preferences in user.js can't be turned off the same way by overrides. However, the merging mode doesn't turn on preferences that way as long as they are lines that begin with user_pref within multi-line comments in user.js, as explained (in different words) by @earthlng here.

I've been wondering for a while whether it would be worthwhile or not to make the script smarter interpreting and handling preferences, considering all the ways they can appear in user.js. What do you think? What would be an ideal criteria for you?

To elaborate on my previous comment, a -hopefully- concise example:

source user.js contains:

/* Begin multi-line comment
user_pref("example", false);
   end multi-line comment */

user-overrides.js contains:

user_pref("example", true);

Resulting user.js with append mode (default):

/* Begin multi-line comment
user_pref("example", false);
   end multi-line comment */
user_pref("example", true);

Resulting user.js with merge mode:

/* Begin multi-line comment
user_pref("example", true);
   end multi-line comment */

I figured I was probably missing something in my reasoning. Thanks for the clarification.

I was thinking that BOTH updater scripts, when appending only, should add an override parrot at the start and end - just a thought

I considered that too some time ago, but didn't bother with it in the end. It's easy to implement though, just a couple of lines of code.

EDIT: I made it add a parrot both in append and merge modes, because some lines can be appended in merge mode anyway 05ac6dd EDIT: (we dropped this idea afterwards)

3.1:

• Disable the network connection
  • Optional: recommended for large lists

I would rewrite that to:

[optional] disable the network connection (recommended for ghacks-clear-all-up-to-57-[the-rest-active].js !)

IMO we can also remove the Script Example from that page.

• done

3.2: 👍
3.3:

• the folder for multi-js must be named user.js-overrides
• Mac/Linux
  • ~~You can run it and it will backup ... ~~ => It will backup ...

I still don't really understand why disconnection is needed

mostly to keep a clean profile. If you reset all active+inactive prefs then basically everything is reset to FF's default, ie it could start to download all kinds of updates. For example if someone takes a while to look at the remaining user-set prefs in about:config, or the log in the console, or doesn't immediately restart FF for whatever other reason.

... and system addons!

well it's a bit weird/confusing that it says optional and then recommended. Maybe (recommended for *[the-rest-active].js + *[the-rest-inactive].js) - that should maybe fit on a single line. Or if it doesn't, use a sub-bullet-point for that line (and in that case perhaps use the full names of those 2 files).

We should also add a recommendation in 3.2 to use parrot prefs in override files.

IDK. it's totally unnecessary for [changes-only].js, [RFP-alternatives].js, [deprecated].js, [removed].js, and all future [changes-only].js files. And you also only need to run the other 2 files at most ONCE, so I don't think it makes sense to recommend to disable the network connection as a general rule.

the files are named clear-all-up-to-57 for a reason. ESR52 users shouldn't run any of these, at least not without editing them.