changelog: v103

[Thorin-Oakenpants]

date: 18-August-2022

FF103 release notes
FF103 for developers
FF103 security advisories

CHANGELOG

• all changes
• ToDo: diffs FF102-FF103 issue
• v103 PR is at v103 #1508

---

⭐ For the long story on the clearOnShutdown* and cookie.lifetimePolicy pref changes, see the first post in #1491

• new in user.js v103

user_pref("geo.provider.use_geoclue", false); // [FF102+] [LINUX]

• changed values in user.js v103

user_pref("privacy.clearOnShutdown.cookies", true); // was false
user_pref("privacy.clearOnShutdown.offlineApps", true); // was false

• made inactive and moved to personal in user.js v103

// user_pref("media.autoplay.blocking_policy", 2);

• moved to 9999: DEPRECATED / REMOVED in user.js v103
  • note: cookie.lifetimePolicy : FF103 code will always reset this to 0, technically removed in FF104

user_pref("network.cookie.lifetimePolicy", 2);
user_pref("security.pki.sha1_enforcement_level", 1);

---

⭐ your friendly reminder to run prefsCleaner

---

NO STATS. NO ALL HAIL PANTS. UNTIL NEXT TIME.

[aleyvo]

Thanks Pants.

[opusforlife2]

It might be clearer to state "click-to-play only" instead of "user" in:

user.js/user.js

Line 1266 in 0dba336

// 0=sticky (default), 1=transient, 2=user

That's what I've added in a comment in my overrides.

---

Also, could you please add a one-liner to explain this setting?

user.js/user.js

Line 771 in 0dba336

// user_pref("privacy.clearOnShutdown.siteSettings", false); // [DEFAULT: false]

It's not clear from the UI or the user.js. The clearest explanation I've found is #119 (comment).

[fxbrit]

NO ALL HAIL PANTS

:-((((

[crssi]

Thank you @Thorin-Oakenpants and others too. ❤️

[rusty-snake]

@opusforlife2

https://searchfox.org/mozilla-central/rev/db4b1d66c4b409bdbce43f3f3498401f5303d961/browser/modules/Sanitizer.jsm#538

          Ci.nsIClearDataService.CLEAR_PERMISSIONS |
            Ci.nsIClearDataService.CLEAR_CONTENT_PREFERENCES |
            Ci.nsIClearDataService.CLEAR_DOM_PUSH_NOTIFICATIONS |
            Ci.nsIClearDataService.CLEAR_CLIENT_AUTH_REMEMBER_SERVICE |
            Ci.nsIClearDataService.CLEAR_CERT_EXCEPTIONS

[practik]

Well I'll say it:

ALL HAIL PANTS

Collect the set

• Red Pandas, Puss, Trash Pandas, Sting, Mr. Nutterbutter, Snow Leopard, Orko, Polar Bear, Minion Horde

You moved a lot of furniture around in 2800 and it's a lot better now (although I think this did get lost in the shuffle: * [SETTING] Privacy & Security>History>Custom Settings>Clear history when Firefox closes>Settings). Thanks for all the work!

[Thorin-Oakenpants]

although I think this did get lost in the shuffle

user.js/user.js

Lines 757 to 759 in 0dba336

	/* 2810: enable Firefox to clear items on shutdown
	* [SETTING] Privacy & Security>History>Custom Settings>Clear history when Firefox closes | Settings ***/
	user_pref("privacy.sanitize.sanitizeOnShutdown", true);

What is missing is Privacy & Security>Cookies and Site Data>Delete cookies and site data when Firefox is closed. And by that I mean the new behavior (ignore that it is listed under deprecated)

toggling that checkbox flips sanitizeOnShutdown cookies/offlineapps/cache (we already have 2810 = true with other items to clear). I haven't fully tested what happens in all configs. If 2810 is enabled then it just flips those three items but if 2810 is disabled, it will obviously enable it and those three items, and the rest I'm not 100% sure on - I think it uses the migration logic (or maybe it recognizes user modified values)

Anyway, I was going to add that somewhere, and simply say, leave this alone, we control it's state via 2800 ">History>" settings

• e.g if someone decides to not delete cache on shutdown (and that's ok) then the UI becomes unchecked, and then they think cookies + site data is not being cleared

[practik]

Ah, I get it now – I vaguely wondered what | Settings meant. Thanks.

I was going to add that somewhere

I guess a note at the top of 2800?
* [NOTE] Ignore [SETTING] Privacy & Security>Cookies and Site Data>Delete cookies and site data when Firefox is closed
* This setting toggles sanitizeOnShutdown prefs for cache (2811), cookies and offlineapps (2815).
* We set those prefs individually, so the checkbox may not correctly indicate their state.

[Thorin-Oakenpants]

You moved a lot of furniture around in 2800
I guess a note at the top of 2800?

2800 has become a sprawling behemoth .. I am loathe to add more to it: and it doesn't help that ESR102 behaves differently

---

@opusforlife2

It's not clear from the UI or the user.js [siteSettings]

= site settings .. like permissions (cookies+site data, notifications, geo ... etc ... ETP exceptions), zoom levels (except RFP ignores those), etc.

The UI is

- History
   - browsing & download history = `.history` + `.downloads`
   - active logins = `.sessions`
   - form & search history = `.formdata`
   - cookies = `.cookies`
   - cache = `.cache`
- Data
   - site settings = `.siteSettings`
   - offline website data - `,offlineApps`

It's not as clean as it could be, and there are plans to tidy it up. Cookies + Active Logins + Cache should be next to offline website data under data. They should rename "offline website data" to "Site Data" to be consistent. Cache should be there as well, since it's linked to cookies + site data (and I hope they get around to cache respecting site exceptions to tidy that up so they all behave the same)

I have explained .sessions in 2811 and .offlineApps = "Site Data" in 2815, as these are the only two IMO that are ambiguous. The rest are all intuitive

What I'd like to see is something like

- History
   - browsing & download history
   - form & search history
- Site Settings
   - site permissions and exceptions
- Cookies and Site Data
   - active logins <-- so vague what this is for users
   - cache
   - cookies
   - website data

and everything under "Cookies + Site Data" should respect site exceptions, and be flipped by the "clear cookies + site data" checkbox. This would align naming and behavior

[opusforlife2]

Thanks for explaining, Rusty-Snake-In-Pants.

as these are the only two IMO that are ambiguous. The rest are all intuitive

siteSettings isn't ambiguous once you know it, but it did require some digging which finally took me to the comment I linked above. The question for me arose because as I went through the list, seeing all the settings that are cleared and then encountering one that isn't, made me pause and wonder "why not"? There is an explanation for the others, after all, but not this one. Even this by itself would be helpful:

permissions, ETP exceptions, zoom levels, certificate exceptions, etc.

just to get a basic idea and move on with the rest of the user.js.

---

What about my other suggestion?

[Thorin-Oakenpants]

permissions, ETP exceptions, zoom levels, certificate exceptions, etc

actually these (cert exceptions) are kept elsewhere, AFAIK

edit this exact quote is nowhere to be found, I never quoted cert exceptions

[Thorin-Oakenpants]

What about my other suggestion

really? you can't extrapolate "user" to mean "click to play"

[opusforlife2]

really? you can't extrapolate "user" to mean "click to play"

Well, no. In fact, none of the 3 options are clear, with the way the pref is named. The term "blocking policy" implies under what conditions autoplay should be allowed or blocked. But the pref is actually about the duration for which an already given autoplay exemption stays in place. It could have been blocking_duration_policy or something instead.

Because of this, the policy documentation needs to be read to understand the term used for each option. And the documentation itself is written in a slightly convoluted way and takes time to digest (which is weird because Mozilla is usually very good at simplifying things in their docs; maybe this was originally not meant to be a public document).

I would rather go with:

// user_pref("media.autoplay.blocking_policy", 2); // duration for which autoplay exemption is given if you interacted with the site

0 = until page close/reload, 1 = until timeout, 2 = none/no exemption (click-to-play only)

Even if you don't want to change the other stuff, the policy documentation itself uses the term "click-to-play" for the third option, and is much easier to understand.

---

this exact quote is nowhere to be found

Sorry, that wasn't meant to be read as a quote. I'll change it to a code block.

[mik0l]

There was one pref, now to delete cookies have to:

user_pref("privacy.clearOnShutdown.downloads", false);
user_pref("privacy.clearOnShutdown.formdata", false);
user_pref("privacy.clearOnShutdown.history", false);
user_pref("privacy.clearOnShutdown.offlineApps", true);
user_pref("privacy.clearOnShutdown.sessions", false);
user_pref("privacy.sanitize.sanitizeOnShutdown", true);

It's not really convenient.

[rusty-snake]

None of the prefs you listed has changed. What do you try to say?

---

And FTR network.cookie.lifetimePolicy got removed functionally and technically.

[mik0l]

Is there a difference between writing one pref in user.js and six?
It's cumbersome.

And the gmp-clearkey cookie is not deleted: #1199

[rusty-snake]

1. Two of the prefs you listed are set to the same value in the user.js. It's useless to set them in your overrides too.
2. You do not need any overrides to delete cookies.
3. gmp-clearkey isn't a cookie. Your statment is just FUD.

[Thorin-Oakenpants]

There was one pref, now to delete cookies have to:

user_pref("privacy.clearOnShutdown.downloads", false);
user_pref("privacy.clearOnShutdown.formdata", false);
user_pref("privacy.clearOnShutdown.history", false);
user_pref("privacy.clearOnShutdown.offlineApps", true);
user_pref("privacy.clearOnShutdown.sessions", false);
user_pref("privacy.sanitize.sanitizeOnShutdown", true);

four of those (downloads, formdata, history, sessions) have nothing to do with cookies or site data and are default true

why did you change sessions - read the user.js

as for the other two, you've always had to set those to delete on close - we always used to do it that way until I think about v91 we switched to lifetimepolicy and now back again

It's not really convenient.

FFS: how many times do you need to set things

[mik0l]

3. gmp-clearkey isn't a cookie. Your statment is just FUD.

What are they on the dropbox site for then?

[rusty-snake]

What has dropbox to do with this.

[mik0l]

why did you change sessions - read the user.js

It's not me, it's when you set the checkbox to delete cookies and site data.

FFS: how many times do you need to set things

I'm not talking about me, I'm talking about firefox users in general.

[rusty-snake]

You change it, read your own comment:

user_pref("privacy.clearOnShutdown.sessions", false);

[mik0l]

This is changed by firefox itself, so I wrote it down that way.
I only need to delete cookies and data.

That's what I'm talking about, the confusion due to the large number of prefs.

[Thorin-Oakenpants]

why did you change sessions - read the user.js

It's not me, it's when you set the checkbox to delete cookies and site data.

that checkbox does not alter .sessions, it toggles cache, offlineapps and cookies

[mik0l]

that checkbox does not alter .sessions, it toggles cache, offlineapps and cookies

Yes, but with the new profile he created it in false.
I'm already confused myself about what to set.

[Thorin-Oakenpants]

Yes, but with the new profile he created it in false

it is default true on new profiles. arkenfox also enforces it to true - the only reason it is false, is because you changed it in your overrides

[mik0l]

Yes, but with the new profile he created it in false

it is default true on new profiles. arkenfox also enforces it to true - the only reason it is false, is because you changed it in your overrides

Default: true
Set the checkbox to delete cookies and site data: false
Arkenfox: true

[Thorin-Oakenpants]

the code for the checkbox does not touch .sessions.

• open about:config : type in n.sessions - it should be true
• in a new tab open preferences > security
• toggle delete cookies and site data when firefox closes
• check about:config (which updates in real time)
  • .sessions remains true

you might be talking about the migration code

• here is the code - in this case this is it being removed from 102
• and it only changes these to false IF clearonshutdown wasn't enabled (to make sure users who didn't have it enabled, don't suddenly lose history, downloads, etc) - in other words, respecting previous choices and only removing cache, cookies and offlineapps (as per the description of the UI)

We are halfway thru the FF104 cycle where the lifetime policy pref has been removed (and thus the migration code)

AND arkenfox 103 moved lifetime policy to deprecated, so if you ran prefscleaner then it would have been reset, and if you didn't then since AF has clearonShutdown enabled, it would not reset anything as false

[Thorin-Oakenpants]

the code for the checkbox does not touch .sessions.

ok, the penny dropped. new profile w/out arkenfox. This is not my problem. And if it is with arkenfox, then you would have had to override clearonshutdown master switch to false, which you would actually want to be true because you then asked it to sanitize shit on close, by playing with the UI

I'm not going to bother looking it up, but the same logic as migration should also apply to toggling the UI. Default new profile does not have clearonshutdown enabled - so the code is doing exactly as expected (see previous comment) - but arkenfox does have it enabled, and it explicitly sets all values concerned. I do not care about a default new profile. I only care about arkenfox

for you to have .sessions being changed to false, you would have to override clearonshutdown and check (perhaps uncheck first) the checkbox - and why are you using the UI - all the settings are actively set in the user.js, so the UI changes will not stick. You need to add them to overrides

[mik0l]

and why are you using the UI

I needed the UI to know what to override.
I told you they added headaches with these prefs.

[rusty-snake]

You do not need to override anything to delete cookies. Arkenfox has always deleted cookies in shutdown unless you said other.

#1526 (comment) (2)