We can't distinguish a policy whose callbacks completed from whose where the callback failed. This could give false assurance that a policy was enforced.

STR: Apply this policy, restart Firefox, then open about:policies and about:addons:

{
  "policies": {
    "ExtensionSettings": {
      "my-broken-extension@example.com": {
        "installation_mode": "force_installed",
        "install_url": "http://"
      }
    }
  }
}

Result: ExtensionSettings is displayed under Active policies, but the requested extension was not installed. Currently, the rejected installation promise is also not associated with the policy, so the Errors tab remains empty.

Expectation: An unsuccessful policy operation should be reported in about:policies. We may want to report it as partially applied, but open to discussion.

Notes:

The Preferences policy is another repro:

{"policies": {"Preferences": {"browser.startup.page": "1", "browser.altClickSave": true}}}

browser.startup.page is an integer, but we give the string "1". The type mismatch causes the callback to throw before browser.altClickSave is processed:

Services.prefs.prefIsLocked("browser.altClickSave"); // false: the later entry was not processed 
Object.hasOwn( Services.policies.getActivePolicies(), "Preferences" ); // true: the policy is nevertheless reported as active

• Bug 2067099 provides a separate example: a Handlers callback throws before completing, but the policy is still reported as Active.

A policy whose callback failed was indistinguishable from one that applied
cleanly: getActivePolicies() listed it, and an async callback's rejection was
not observable at all, so nothing reached about:policies.

The policy engine now records a failure against the policy whose callback
threw or whose returned promise rejected. Policy implementations that need to
keep going after a single failed operation report it the same way, so one bad
preference, certificate or match pattern no longer looks like a clean
application. Preferences also no longer discards the entries after one that
fails.

about:policies flags those policies in the Active list and names the policy
each message belongs to in a new column of the Errors tab. Failures logged
from PoliciesHelpers were never displayed there at all.

getActivePolicies() is unchanged: those parameters are what the administrator
asked for, and callers rely on that.

Handlers still reports through the engine's generic handler; containing its
mimeTypes loop so it can name the entry that failed is left for a follow-up.

Authored by https://github.com/bsmth
https://github.com/mozilla/enterprise-firefox/commit/02a7c816c63d0b1b0e594884fe93ec70ae2648c7
[enterprise-main] Bug 2067123 - improved handling of policy failures

Authored by https://github.com/bsmth
https://github.com/mozilla/enterprise-firefox/commit/987cfee009e7a588b180ab2d99cb2e7adf90af4a
[enterprise-main] Bug 2067123 - improved handling of policy failures, fixes from review

Authored by https://github.com/lissyx
https://github.com/mozilla/enterprise-firefox/commit/178467431624c800e4ee7ac6db959c9346cf9418
[enterprise-main] Merge pull request #1402 from bsmth/policy-engine-errs

https://hg.mozilla.org/mozilla-central/rev/2dfecab43c5e
https://hg.mozilla.org/mozilla-central/rev/39e5fc8f6fd9

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

(cherry picked from commit 97652a82f9b00fd400a94271fc8f0352585ddd6c)

Rebased for ESR 153: Bug 2048572, which moved the Policies helper functions to
toolkit/components/enterprisepolicies/PoliciesHelpers.sys.mjs, is not on
ESR 153. PoliciesHelpers.sys.mjs is added here containing only the new
PolicyFailures state and reportFailure, which EnterprisePoliciesParent and the
browser-side policy helpers both need. The other helpers keep their existing
home in browser/components/enterprisepolicies/Policies.sys.mjs, so their call
sites stay unprefixed and applyExtensionGuards, installAddonFromRepository and
installAddonFromURL take their policyName changes in place.

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

(cherry picked from commit c6bac48c25adacb20339375b1666e1af0c4d3d32)

Rebased for ESR 153: describePreferenceFailure is added to the trimmed
PoliciesHelpers.sys.mjs introduced in the previous patch, and processMIMEInfo
takes its policyName change in place in
browser/components/enterprisepolicies/Policies.sys.mjs, where ESR 153 still
keeps it.

firefox-esr153 Uplift Approval Request

• User impact if declined/Reason for urgency: We added a new policy schema in 153 and we're finding some things that aren't working the same as before. Want to get them fixed before we migrate everyone.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Policy only, lots of testing on release.
• String changes made/needed?: String changes: adds one new string, policy-not-fully-applied ("Not fully applied"), to browser/locales/en-US/browser/aboutPolicies.ftl. It is a badge shown next to a
  policy's name in the Active tab of about:policies when some of that policy's operations failed; the Errors tab already has the details. No existing strings are
  changed or removed, and no other locale files are touched. about:policies is an enterprise admin diagnostic page, so an untranslated string there falls back to
  English on the same page as the rest of the (already English-only) policy names.
• Is Android affected?: no

Verified fixed on 157.0  (20260925115502) using the Handlers policy and the errors are showing as expected in about:policies#errors. Tested on Windows 11 and Ubuntu.