rethink deprecated/ESR/updater

[opusforlife2]

I'm using the 115.1 ESR user.js. Now I want to edit some prefs in my overrides. But running the updater will download the latest user.js instead of the ESR.

My intended approach is to point the Github URL in the updater.bat to the 115.1 release.

Is this the correct way, or am I missing something?

[c3d1c06c-bf26-477e-b0eb-c50ef4477ba6]

Latest version is fine, just make sure to run the updater with the esr option (-e or -esr).

[Thorin-Oakenpants]

I don't use the updater at all, so I can't vouch for the esr option. Since I changed the format (in v118, upcoming) I think that command is now useless

So what did people do in the past to keep the ESR version of AF but make changes. Probably just add them to the end and keep a copy in an overrides ?

[c3d1c06c-bf26-477e-b0eb-c50ef4477ba6]

It's broken for v118 but just needs a tiny fix.

[Thorin-Oakenpants]

what's the tiny fix, so I can add it

[Thorin-Oakenpants]

don't forget that the values are blanked and al the prefs are commented out

[Thorin-Oakenpants]

Just to be clear, the whole point I did this was to force users on ESR to use the 115.1 AF version - I totally forgot about the updater (and commands)

[Thorin-Oakenpants]

I need to drink on this. What I might do is blank and comment out the shit ESR shouldn't use, but leave the others in. And I will also add a warning at the top that you're on your own )e.g. when I move to FPP, ESR users will fail on that front since it wasn't even hooked up

[c3d1c06c-bf26-477e-b0eb-c50ef4477ba6]

Windows, line 145:
CALL :activate user.js.new ".x still uses all the following prefs"->CALL :activate user.js.new ": deprecated FF"

I see that section 9999 now has a 9998. That doesn't make any sense. How do you want to handle that, like 999x?

In that case for Linux, line 285:
sed -e 's/\/\* \(ESR[0-9]\{2,\}\.x still uses all.*\)/\/\/ \1/' user.js > user.js.tmp && mv user.js.tmp user.js->sed -e 's/\/\* \(999[0-9]: deprecated FF.*\)/\/\/ \1/' user.js > user.js.tmp && mv user.js.tmp user.js

[Thorin-Oakenpants]

I see that section 9999 now has a 9998. That doesn't make any sense

does to me :)

it's only for one release, because v119 I strip out all the old ESR102 shit, and I wanted to split them

---

so in the past (for the 4 release overlap of ESRs: I needed to keep them an extra cycle so once EOL it was still there the next release for prefsCleaner), and depending on if there were any deprecated items .. it looked like this (using 102 + 115 as an example)

/*** [SECTION 9999]: DEPRECATED / REMOVED / LEGACY / RENAMED
   Documentation denoted as [-]. Items deprecated prior to FF91 have been archived at [1]
   [1] https://github.com/arkenfox/user.js/issues/123
***/
/* ESR102.x still uses all the following prefs
// [NOTE] replace the * with a slash in the line above to re-enable them
// blah blah
// ***/

/* ESR115.x still uses all the following prefs
// [NOTE] replace the * with a slash in the line above to re-enable them
// blah blah
// ***/

So does the esr option flip both? If so, that's a little messy, but not a deal breaker, because setting deprecated prefs won't do anything - e.g. if you're on ESR115 and you set ESR102 prefs - but then I remove those and prefsCleaner never gets to "clean" the active ones

It's all a bit messy, and quite frankly, I want to do away with the ESR section and deprecated. I will still list deprecated, but I think I will just stick it all under 6050s

---

what the updater needs is a command to skip updating the user.js and just go straight to appending overrides (and to remove the esr option)

---

Class, discuss! Speak now or forever hold something

[g-2-s]

What I always do:
1 . download the user.js relevant to the ESR version of Firefox
2 . manually append my user-overrides.js to said user.js
3 . start Firefox and close Firefox
3 . run prefsCleaner.bat or prefsCleaner.sh
4 . profit I guess
Let me know if this method is wrong because from my end it just works.
EDIT: I'm pretty sure I do this for the Release branch of Firefox as well, now that I think about it I never use the updater, I always thought the prefsCleaner was way more important but do correct me if I'm wrong (I probably am).

[Thorin-Oakenpants]

@g-2-s yeah, that's how I would do it - i.e not use the updater because I do not want the latest version, and just manually add my overrides (and keep a copy), and of course run prefsCleaner

prefsCleaner is only needed once per release - but if you adding then removing overrides of inactive prefs in the user.js, then it helps - i.e there are edge cases where prefsCleaner absolutely helps and saves your ass, and running it cannot hurt you

example

• user.js has // user_pref("javascript.options.asmjs", false); i.e commented out
• prefsCleaner resets this to default (true)
• you add override to disable it (false), it gets set to that in your Firefox
• later you remove the override
• nothing was done to reset the pref in your FF - you either need to do it manually, or run prefsCleaner

[opusforlife2]

what the updater needs is a command to skip updating the user.js and just go straight to appending overrides

That's probably the most straightforward solution for the future.

From reading the conversation until now, what I've understood is that I'll have to manually edit both the user.js and the overrides files simultaneously for whatever pref I'm changing, and then run prefsCleaner.

[Thorin-Oakenpants]

@opusforlife2 yeah, for now. I need to drink on this - the updater will always get the latest version, and by the time ESR users reach EOL, they don't even get the next ESR release, because we're three releases past that.

So

• at the very least we need to update the wiki
• maybe we move deprecated stuff into the 6050's + remove the esr option in updater
• maybe the updater can check if the app release channel and abort updating but still append overrides

[opusforlife2]

Maybe a separate naming scheme for ESR releases + different release channels? Regular and ESR?

[Thorin-Oakenpants]

not going to have two release channels - once the ESR version is released, that's it

[Thorin-Oakenpants]

some notes/thoughts

ESR78-91 transition - I added the ESR91.x **above** the ESR78.x lines. Also nothing was removed that was active during this transition (92-94), but there were 12 active items in the ESR78.x lines. In v95 the old ESR78.x was stripped out. The entire overlap was 2 deprecated prefs (both inactive)

ESR91-102 transition - the order was reversed - 91 first then 102. I think this is the correct/best order so at least the older ESR is flipped with the esr option. So ESR102.x came after ESR91.x. The ESR102.x contained active items. In v106 the old ESR191.x was stripped out. The entire overlap was 2 deprecated prefs (1 inactive, 1 active)

ESR102-115 transition - order maintained, i.e 102 first then 115 😁 I only have to do this once a year, so I guess It's whatever my brain says at the time. We would remove the ESR102.x lines in v119. The entire overlap is 6 prefs and only two are active - one of which I am going to change [1]

[1] permissions.delegation.enabled was goinbg to change to inactive and don't touch, but instead waited for the deprecation. I will make it inactive in section 9999

---

So each transition we end up with two lots of ESR flips, with the newer lot having at least 1 active pref - sometimes super important like cookieBehavior, sometimes minor shit like MS family safety. IDK if the esr-option flips both.

For the actual changeover release, I can move the old ESR to 6050s, because by then the order should be reversed (assuming only 1 char flip)

This is why I do not want to deal with the entire 9999 section and an esr-flip. It gets so convoluted and messy.

[Thorin-Oakenpants]

OK

• the mess of an ESR overlap is but once a year - so ignoring this for the next 9 months - maybe the next one won't have anything
• keeping the 9999 section with all detail data
  • 1. it's my only copy put in sticky: deprecated-removed-legacy prefs #123
  • 2. it still allows those who wish to, to flip it, so I don't have to fuck around with the updater
• added some ESR recommendations in the user.js releases bit - hope t makes sense
• will update wiki
• forget about it for 9 months and drink some more

@opusforlife2 , does this cover your concerns

* RELEASES: https://github.com/arkenfox/user.js/releases

  * Use the arkenfox release that matches your Firefox version
    - DON'T wait for arkenfox to update Firefox, nothing major changes these days
  * Each release
    - run prefsCleaner to reset prefs made inactive, including deprecated (9999)
  * ESR
    - It is recommended to not use the updater, or you will get a later version which may cause issues.
      So you should manually append your overrides (and keep a copy), and manually update when you
      change ESR releases (arkenfox is already past that release)
    - If you decide to keep updating, then the onus is on - also see section 9999

[Thorin-Oakenpants]

@opusforlife2 - also see https://github.com/arkenfox/user.js/wiki/3.4-Apply-&-Update-&-Maintain#-esr-users

awaiting your feedback so I can close and get back to drinking - thanks for the improvements, which were clearly needed ;) 👍

[opusforlife2]

I'm only stuck on ESR because of Windows 7. Otherwise I would have updated regularly. So the part relevant to me is the exact process for safely making changes to prefs without accidentally updating the user.js.

Basically this part:

manually edit both the user.js and the overrides files simultaneously for whatever pref I'm changing, and then run prefsCleaner.

If you want to put that in the wiki for other ESR users, it would need a separate heading, I think.

But if there is going to be a command for strictly locally updating the user.js like you mentioned above, then this doesn't need to be mentioned.

[Thorin-Oakenpants]

there won't be an command to only append overrides unless someone does it - but I'll add an issue

the wiki and user.js already say what you asked

[opusforlife2]

I don't know, maybe I'm misinterpreting something. The stuff you've referred or linked to only talks about updating to a new version, whether release to release or ESR to ESR. Not about staying on the same version and still wanting to change a pref around.

[Thorin-Oakenpants]

here's the user.js (v118 when I land it)

• run prefsCleaner
• ESR users don't run updater do everything manually

  * Use the arkenfox release that matches your Firefox version
    - DON'T wait for arkenfox to update Firefox, nothing major changes these days
  * Each release
    - run prefsCleaner to reset prefs made inactive, including deprecated (9999)
  * ESR
    - It is recommended to not use the updater, or you will get a later version which may cause issues.
      So you should manually append your overrides (and keep a copy), and manually update when you
      change ESR releases (arkenfox is already past that release)
    - If you decide to keep updating, then the onus is on - also see section 9999

here's the wiki - https://github.com/arkenfox/user.js/wiki/3.4-Apply-&-Update-&-Maintain#-esr-users

• says the same thing under recommended
  • do not use updater, update user.js manually when required, manually add overrides, keep a copy of overrides, run prefscleaner

[opusforlife2]

Maybe we're talking past each other? I'll propose some edits to the PR.