browser.contentblocking.category blocks ETP prefs [1607249]

[crssi]

/* 2701 */
user_pref("network.cookie.cookieBehavior", 1);

is ignored, unless

user_pref("browser.contentblocking.category", "custom");

browser.contentblocking.category is missing in user.js and thus set by default to standard.
ATM user must manually change in GUI to custom.

Cheers

[crssi]

No, it is not.
I have tried with a new profile before posting an issue 😉 .
Maybe this is new to latest FF.

[crssi]

Its not only the latest FF, it looks like FF 70 also.

[earthlng]

Prefs in about:config are (often) tied to a prefs-observer which then does things like "automatically" change this thing to "custom" etc. But that's not (or not always) the case when a pref is applied from a user.js.
So I guess the STR would be to let the user.js apply the cookie pref and then check if the GUI correctly changed to custom

[crssi]

Here is the video: https://www.dropbox.com/s/at740nllocidetp/ffvideo.mp4?dl=0

Windows 10 up-to-date, FF 71 x64.

I can replicate on every computer.

[crssi]

You can also simply test with your working profile (where u have user.js).
Change to Standard... restart FF. Is should be Custom, due to user.js, but it persist to Standard.

[earthlng]

At first I wasn't able to reproduce it ie I put a user.js with the cookie pref = 1 into a new profile, started FF and the category was correctly set to custom.
BUT once you change it to "standard", it sticks!
What I think is happening is that initially on FF start the user.js is correctly applied but then at some point FF sees .category=standard and resets all the relevant contentblocking prefs including the cookiebehavior.
I tested FF71 and todays Nightly and it's the same behavior in both. Ideally we should let mozilla know and get this fixed upstream but until then, yes I think we should enforce the category pref to custom.

Thanks @crssi, good find!

@Thorin-Oakenpants would you mind opening a ticket? thank you ;)

[crssi]

Looks like your approach to new profile might be different to mine.
STR:

1. Close FF
2. Delete FF profile folders, that is %appdata%\Mozilla\Firefox
3. Start FF, so profile folder with initial files are created.
4. Close FF
5. Add user.js into profile folder
6. Start FF... there is Standard instead of Custom, despite the value 1 in the user.js

Here it is reproducible every single time.

Cheers

[earthlng]

open a ticket where? at moz?

yes. Pretty please ... :)

Looks like your approach to new profile might be different to mine.

correct, I didn't do 3 + 4 in your STR. In step 3 the category gets set to "standard" and apparently once that's set, it sticks.
If you do 5 before 3, it'll correctly set the category to custom.

It's easier to test with FF portable because you can just create an empty "profile" folder under "Data" and put the user.js in there before you start FF for the 1st time with that profile.

If you want to test it your way, you can do 1, 2 + 3 to let FF create the randomly named profile folder, then delete everything in there, put the user.js in and then start FF again.

[crssi]

You don't need an empty profile.
Just change to Standard and restart FF. It will stay in standard and will not block 3rd party cookies, despite the value 1 in user.js

[earthlng]

The main issue is that once browser.contentblocking.category is set to standard (either manually or otherwise), all those ETP prefs are no longer honored when set from a user.js. ("no longer honored" = I'm pretty sure they get initially applied during startup but then later reset or overwritten when FF sees .category="standard")
And it's not the UI page itself that does the resetting, it happens during startup

[earthlng]

AFAICT, in FF71 the affected ETP prefs are all of these:

• network.cookie.cookieBehavior
• privacy.trackingprotection.pbmode.enabled
• privacy.trackingprotection.enabled
• privacy.trackingprotection.socialtracking.enabled
• privacy.trackingprotection.fingerprinting.enabled
• privacy.trackingprotection.cryptomining.enabled

[earthlng]

Since network.cookie.cookieBehavior is the only pref out of those that we still have in the user.js, IMO we can just add the category pref to 2701 and keep it there until after the next ESR gets released, assuming they'll have fixed the issue by then.

[earthlng]

FYI ESR 68.3.0 has the same problem.

[earthlng]

I don't think this is quite true anymore.

why not?

The main problem is when someone applies the user.js to a profile with ETP=standard, the cookie pref won't get set