Page Info → Permissions ("Set Cookies") locks the cookie controls inconsistently depending on how the Cookies policy is configured. The two controls are the "Use default" checkbox and the Allow / Allow for Session / Block radio group:

• Locked: true, no per-site rule for the site — both controls locked.
• Per-site rule (Allow/Block/AllowSession) set with Locked: true — only "Use default" is locked; the radios are editable.
• Per-site rule (Allow/Block/AllowSession) set with Locked:unset|false — both "Use default" and the radios are editable.

By contrast, about:preferences#privacy > Browsing Data > Manage Exceptions locks every policy-applied cookie permission.

On Page Info the checkbox is only disabled if Locked == true, while the command lock state is decided purely by state == UNKNOWN, never by the policy scope — even though the general rule is that anything set by policy is locked. I believe this was regressed by Bug 1452361 when the Cookies section got special handling.

So I suggest that the checkbox and command should also be disabled when scope == SitePermissions.SCOPE_POLICY.

Set release status flags based on info from the regressing bug 1452361

When initializing the Cookies row on the Page Info, disable the checkbox and
cmd_cookieToggle command when scope == SitePermissions.SCOPE_POLICY, in addition to
the existing prefIsLocked("network.cookie.cookieBehavior") check. This locks cookie
permissions set by the Cookies policy (EXPIRE_POLICY), matching the other permissions

https://hg.mozilla.org/mozilla-central/rev/0041d2791c20

The patch landed in nightly and beta is affected, along with ESR.
:janika, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta and ESR approvals.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox155 and the ESR status flag(s) to wontfix.

For more information, please visit BugBot documentation.

I think we should uplift to esr. Don't worry about 155. It will be there soon enough.

This fix can be verified by repeating the test plan see Bug 2056598 comment 4 until step 1.3. Only difference to before is that "Set Cookies" should now be disabled.

When initializing the Cookies row on the Page Info, disable the checkbox and
cmd_cookieToggle command when scope == SitePermissions.SCOPE_POLICY, in addition to
the existing prefIsLocked("network.cookie.cookieBehavior") check. This locks cookie
permissions set by the Cookies policy (EXPIRE_POLICY), matching the other permissions

Original Revision: https://phabricator.services.mozilla.com/D316902

firefox-esr153 Uplift Approval Request

• User impact if declined/Reason for urgency: The PermissionManager designed to always lock any policy-set Cookie permissions. Without the fix the policy-set Cookies permissions are only partially locked and remain editable for users via the Page Info Permissions Tab while locked anywhere else.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: See https://bugzilla.mozilla.org/show_bug.cgi?id=2061452#c7 for instructions.
• Risk associated with taking this patch: low
• Explanation of risk level: Low
• String changes made/needed?: No
• Is Android affected?: no

Updated Uplift Approval Request

Fix verified in Nightly?: no

Steps to reproduce for manual QE testing:

Create a policies.json file in a distribution folder next to the Firefox binary:

• Windows: <install dir>\distribution\policies.json
• macOS: Firefox.app/Contents/Resources/distribution/policies.json
• Linux: <install dir>/distribution/policies.json

Start the browser and confirm the policy is active by visiting about:policies before each scenario — it should list the Cookies policy and its config.

---Scenario 1 — Cookie behavior locked globally

1. Set policies.json to { "policies": { "Cookies": { "Locked": true } } }
2. Launch Firefox with a fresh profile; verify at about:policies that Cookies is active.
3. Navigate to any site, e.g. https://example.com.
4. Open Page Info (Ctrl+I on Windows/Linux, Cmd+I on macOS; or click the padlock → More Information) and select the Permissions tab.
5. Locate the "Set Cookies" row.

Expected:

• The "Use Default" checkbox is disabled (greyed out, not clickable).
• Both "Allow"/"Allow for Session"/"Block" radio buttons are disabled.
• The user cannot change the cookie setting for the site.

---Scenario 2 — Per-site permission set by policy (Block list)

1. Set policies.json to { "policies": { "Cookies": { "Block": ["https://example.org"] } } }
2. Launch Firefox with a fresh profile; confirm the policy at about:policies.
3. Navigate to https://example.org (the blocked origin).
4. Open Page Info (Ctrl+I on Windows/Linux, Cmd+I on macOS; or click the padlock → More Information) → Permissions and find the "Set Cookies" row.

Expected:

• The "Use Default" checkbox is disabled (greyed out, not clickable).
• The "Allow"/"Allow for Session"/"Block" radio buttons are disabled.
• The user cannot change the cookie setting for the site.

---Scenario 3 — No policy → controls remain editable

1. Remove the policies.json file.
2. Navigate to https://example.org.
3. Open Page Info (Ctrl+I on Windows/Linux, Cmd+I on macOS; or click the padlock → More Information) → Permissions → "Set Cookies".

Expected:

• The "Use Default" checkbox is enabled.
• While "Use Default" is checked, the Allow/Block radio buttons are disabled.
• Unchecking "Use Default" enables the "Allow"/"Allow for Session"/"Block" radio buttons; re-checking it disables them again.