This is a counterpart for: https://github.com/NixOS/nixpkgs/pull/556611
When configPath is overridden, if wrapper supports the new appDataDir
argument, we pass configPath's absolute form to tell the app to look for
its datadir in the correct directory.
This will become necessary on macOS 27+ where Firefox that is not signed
by Mozilla has no access to its default datadir.
Added a new config option programs.firefox.profiles.<name>.storeId.
Setting this option now writes the StoreID both to the profiles.ini
and to the settings."toolkit.profiles.storeID" of the profile.
Firefox has two different profile implementations;
- the old one that home-manager module can declare
- the new "Selectable Profile Service" introduced in 150
The new profiles are managed in a runtime db, and reads from profiles.ini
Migration without database operations is not possible right now,
but when it becomes available, this option will stop home-manager from
clobbering the linked storeIDs.
When a user configures the userChrome option, automatically enable the
`toolkit.legacyUserProfileCustomizations.stylesheets` preference with
`mkDefault` priority so that the user chrome CSS is actually loaded.
The user can still override this in the settings option if needed.
Reject globalExtensions when Home Manager has no browser-managed policy
carrier. This follows up the global extension policy work with a clear
failure mode, a regression test, and a news entry so affected users know
how to fix package = null setups.
This commit adds extensions added via
profiles.<name>.globalExtensions to the policy.
In consequence the extensions are added without complaint and don't need
to be enabled manually.
Co-authored-by: khaneliman <khaneliman@users.noreply.github.com>
Clarify that extensions.autoDisableScopes only handles manual extension approval. Firefox still owns mutable extension runtime state, so impermanent setups must persist the relevant profile state or configure supported extension settings declaratively.
Closes#6398
The package attribute is floorp-bin, but the macOS bundle is Floorp.app. Allow Firefox-family modules to override the derived Darwin app name so Floorp paths match the real package layout.
Restore nested option extensibility for
`programs.firefox.profiles.<name>.extensions` by keeping it as a plain
submodule.
This removes the deprecated `programs.firefox.profiles.<name>.extensions
= [ ... ]` shorthand. Add-ons must now be declared with
`programs.firefox.profiles.<name>.extensions.packages`, while
declarative settings remain under `extensions.settings`.
Add a regression test for downstream `extensions.*` option extension and
a news entry documenting the migration.
Treat Nix paths like plain string preferences when generating user.js so
values such as browser.bookmarks.file are not JSON-quoted twice.
Add a regression case in the Firefox settings test for a path-valued
preference.
This change converts redundant attribute assignments of the form `a =
a;` or `a = someSet.a;` into cleaner `inherit` statements. This reduces
verbosity and follows common Nix style for bringing attributes into
scope.
Statix Codes: W03 (manual_inherit), W04 (manual_inherit_from)
Also include statix and the rule in our configuration.
Adds support for configuring Firefox's handlers.json file to
manage MIME type and URL scheme handlers declaratively (at
`programs.firefox.profiles.<profile>.handlers`). Handlers control
how Firefox opens files and protocols (e.g., PDF viewers,
`mailto:` handlers).
Just default everything to show options to remove confusion / chance of
disabling documentation. We already set visible = true so it wasn't even
being used really.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Add two new options to customize how extension permissions are checked:
- `extensions.exhaustivePermissions`
Ensures that the permissions requested by all extensions managed by
home-manager are authorized
- `extensions.exactPermissions`
When enabled, the user must authorize only the permissions that the
extensions requests, not more nor less.
Adds extension permissions as suggested in
https://github.com/nix-community/home-manager/issues/7001.
Adds the 'profiles.<name>.extensions.settings.<name>.permissions' to Firefox
derivatives. If set, this option adds an assertion that fails if an extension
package requests permissions that weren't added to the permissions option. In
order to not require 'profiles.<name>.extensions.force' to be set when only
permissions, but no extension settings were defined, the relevant assertions
were changed. They now check whether any 'extensions.settings.<name>.settings'
was set instead of checking whether 'extensions.settings' was set.
---------
Co-authored-by: Robert Helgesson <robert@rycee.net>
Co-authored-by: awwpotato <awwpotato@voidq.com>
This resolves issue that someone might try and configure bookmarks and a
policy will prevent it from applying properly.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Add an example of using extension settings to control installation and
accesibility of a extension in the policies option.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Creates the user.js if profile.extensions.settings is set.
This fixes the case when profile.extensions.settings is set but every
other option in the mkIf is false, resulting in no user.js creation.
This allows `programs.firefox.profiles.*.userChrome` to be set to a:
derivation, path/path-like string to directory or file, or multiline
text to be used as content verbatim.
This allows setting, for example(s):
```nix
programs.firefox.profiles."jacob.default".userChrome = pkgs.wavefox;
programs.firefox.profiles."jacob.default".userChrome =
"${pkgs.wavefox}/userChrome.css";
```
The legacy attrset option type for `firefox.profiles.<name>.bookmarks`
was accidentally removed in 9d55428. This adds back support for this
type by refactoring the bookmarks submodule. This also adds a new test
ensuring this won't happen again.
This splits the bookmarks submodule into a seperate file, to make it easier to maintain (like how the search module was previously split out in #5697).
This also refactors bookmarks to require a new force option, to be more explicit about overriding existing bookmarks.
A path may be preferred for some uses, and allowing it avoids the user
needing to `builtins.readFile`, thus creating duplicates and making it
more difficult to determine the actual store path.
