Recommendations for ESR

[GIPeon]

I'm planning on moving my daily usage FFox to ESR 78.

Should I use the 78 version user.js relase or the current one and stay up to date with your commits?

I have RFP enabled, I'm not sure what to do with section 4600, should I update something there even if I was using RFP with the normal version of FFox? I usually use the updater + prefsCleaner scripts is that sufficient?

I've found a similar question in #802 but I'm not sure the discussion really put a definitive point on the issue.

Thank you all for your work and time and for any suggestions you can share!

[Thorin-Oakenpants]

pretty much any changes we do in 79 or higher will not make one iota of difference to ESR, so for ease of use, just use the 78 version

otherwise, all you're doing is updating each user.js release and flipping the ESR78.x section on (and maybe RFP alts section) .. for no gain - i.e prefs we move to deprecated, you re-enable. New prefs won't do anything - but it is conceivable that we add and flip a pref existed in 78 but wasn't quite ready: e.g. HTTPS-Only Mode .. and old prefs are pretty much stable and set .. but it conceivable that we flip a pref or make it inactive, but we're usually very careful with regards to ESR

[GIPeon]

Thank you for your answer and sorry for the late response, I will go ahead with version 78 and keep an eye on on commits (for example the increased cache memory to 65MB for #941 seems a nice thing to have).

If I can ask a last question, in section 4600 is stated (bold is mine):

ESR RFP users:
Reset those up to and including your version. Add those after your version
as active prefs in your overrides. This is assuming that the patch wasn't also
backported to Firefox ESR. Backporting RFP patches to ESR is rare.

Since last version in section 4600 is marked as 67+ I guess I can ignore this? (side note, why very old versions from 55 are still marked? For possible backward compatibility?)

Thanks a lot for your time!

[Thorin-Oakenpants]

Actually, the last item is not 67+ .. I dropped the version notation (e.g. 4618 is FF80+). The version is when it got covered by RFP .. and now I'm not sure on 4617 .. sorry, my brain is totally zonked right now

edit: told you my brain was zonked ... 4618 isn't even in version 78

[Thorin-Oakenpants]

0f6957b

[Thorin-Oakenpants]

@GIPeon .. I might roll the numbering back and redo a 78 release

[GIPeon]

AFAICT for ESR spefic prefs are just a handful < 4600 (3 if I counted well), and the only one that looks to me to be interesting is this in 1003

user.js/user.js

Lines 589 to 592 in fe0af3b

	/* 1003: disable memory cache
	/* capacity: -1=determine dynamically (default), 0=none, n=memory capacity in kilobytes ***/
	// user_pref("browser.cache.memory.enable", false);
	// user_pref("browser.cache.memory.capacity", 0); // [HIDDEN PREF ESR]

I've found your detailed and interesting discussion in #778, but I haven't really grasped all of it, in particular the relationship with TC, and I haven't touched this with my previous regular FFox setup.

So, if I got this right, if I use automatic TC I could leave it as is?

I haven't messed with 1001 either, though I think I could enable it as well due to TC.

---

@GIPeon .. I might roll the numbering back and redo a 78 release

I see interesting thank you! If a re-release of 78 will be done I'll catch up indeed!

[Thorin-Oakenpants]

It's a bit messy to roll back for a new 78v2 release (I'd have to undo the deprecated and the removed)

The 78 release wishlist

• not important: the media cache in PB Mode is bumped up (may help someone)
• not important: RFP Alts: correct versions when RFP protection kicked in and sequential numbering kept

font visibility (4618) is not in the 78 release, so missing the //FF80+ demarcation is not a problem <-- for some reason I kept thinking it was

[Thorin-Oakenpants]

So, if I got this right, if I use automatic TC I could leave it as is

I don't use TC. I assume automatic means every website gets it's own container on every new visit? i.e if you open github = container 123, close github .. revisit github a few minutes later = container 124? I call this "hardened mode"

Most (95% of what FPI does) things are isolated by the container id. Disk cache is OK to enable (1001 = true) but it probably won't do much for you: unless you bounce around in that container for extended periods of time: most of it will already be in memory.

memory cache (1003) I personally wouldn't use these - they're there more for the info that anything else

[GIPeon]

I assume automatic means every website gets it's own container on every new visit? I call this "hardened mode"

I see, yes that's what it does, on every domain it creates a new random container, even with repeated visits (but in my case on github I've setup a specific container rule cuz I'm lazy and don't want to login every time xP ).

Thank you for your insights!