firefox — cross-platform browser management

A firefox role that manages the browser the way git and docker are managed cross-platform: settings, extensions, and per-context profiles as converged state. The browser sibling of the slack per-instance profile model — one isolated profile per client/context, so BWK, Baksteen, Parkos, and Familynet each keep their own session, extensions, and logins.

Firefox splits its configuration across several files with different owners, and the role has to respect that split rather than fight it:

• policies.json — enterprise policy, the only layer that can lock a setting and force-install extensions. Machine-wide, read at every startup.
• user.js — per-profile default prefs the role templates. Firefox owns prefs.js at runtime (it rewrites it on every exit), so the role never touches prefs.js; user.js is the supported seam for defaults.
• profiles.ini / installs.ini — the profile registry and, per install, which profile is the default. Firefox rewrites both at runtime, so any managed edit has to happen with Firefox fully closed or it is clobbered on exit.

Items

• policies.json layer for managed/locked settings and force-installed extensions (uBlock, Bitwarden, Passbolt, containers)
• Templated user.js for per-profile default prefs — never prefs.js, which Firefox owns at runtime
• profiles.ini-declared profiles per client/context, the browser sibling of the slack profile model
• Assert the intended default install profile (installs.ini + the [Install…] Default= in profiles.ini): profile-manager actions (-P, --profile, clicking a profile in the selector) silently flip it to a freshly created …default profile, which is how a launch drops into an empty profile while the real …default-release one keeps running
• Decide how per-context profiles are launched — registered in profiles.ini versus launched by directory with --profile <path> (the current windows inventory launches the Parkos profile by path, so it never appears in profiles.ini); the role should make one choice and converge to it
• When windows_is_wsl, reuse the windows role's interop facts (windows_home, winget install Mozilla.Firefox, the registry / distribution\policies.json path) to manage the Windows install from WSL

Firefox settings and the new-style profiles feature

Recent Firefox ships a built-in multi-profile system (browser.profiles.enabled) that is separate from the classic profiles.ini profiles the slack-style model assumes. When a profile is enrolled it grows a StoreID and ShowSelector in profiles.ini, Firefox may show a profile selector at launch, and each profile is tagged with an avatar rendered as a badge on the toolbar and taskbar icon (the default avatar is a suitcase). Profile-manager poking enrolls a profile into this system as a side effect, so the role has to take a deliberate stance on it.

Open questions

• Opt into the new profiles feature or force it off? Forcing browser.profiles.enabled=false keeps the classic profiles.ini model the per-context design relies on and drops the selector and avatar badges; opting in means owning StoreID/ShowSelector and per-profile avatars as managed state. The two models overlap awkwardly and the role should pick one.
• If opting in, template the per-profile avatar/icon and name so each client profile is visually distinct, or leave icons unmanaged?
• Ubuntu's snap build relocates profiles to ~/snap/firefox/…; prefer the Mozilla apt repo for the standard ~/.mozilla/firefox path (ties into ubuntu_snaps).
• Locked settings need policies.json, not user.js — settle which settings are locked policy versus overridable defaults.