On Linux, both Thunderbird and Firefox use the same directory to contain
native messaging host modules. On this platform, we have to merge both
directories with native hosts into one.
The patch introduces a separate helper module to manage native host
directory generation. Now program modules (firefox, thunderbird) declare
native hosts to initialize; while the new helper module determines
*where* and *how* to merge them on disc.
Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>
Prevents extensions settings from accidentally being overriden when
using `profiles.<name>.extensions.settings`. Adds the
`profiles.<name>.extensions.force` option to acknowledge the risk.
This commit refactors programs.firefox.profiles.<name>.extensions in
order to support both installation of extensions (addons) and their
configuration. It does this by setting the
`extensions.webextensions.ExtensionStorageIDB.enabled` user_pref to
false.
When this preference is set to false, support for storing extension
settings in sqlite databases, also known as IndexedDB or IDB, is
reverted back to the JSON format present in firefox versions prior to
version 63, as seen here:
https://blog.mozilla.org/addons/2018/08/03/new-backend-for-storage-local-api/
IndexedDB was made the default due to performance improvements, but had
the consequence of removing any possibility of declarative extension
configuration without the assistance of firefox's policy system. The
policy system is supported by a small amount of extensions, such as
uBlock Origin, but has to be explicitly supported. Even when supported,
it provides significantly less granular control when compared to the
JSON storage format.
Within the context of the profiles submodule, `${name}` refers to the
profile name, and not the Firefox fork name.
This fixes all descriptions to use the right name. This fixes a
previous commit that introduced a dependency between the documentation
and the user's configuration.
* firefox: fix referencing firefox fork name in profile-specific docs
Within the context of the profiles submodule, `${name}` refers to the
profile name, and not the firefox fork name.
This fixes all descriptions to use `${cfg.name}` instead.
* firefox: prefer cfg.name instead of name for consistency
Add `preConfig`, which acts like `extraConfig`, but placed before
`settings`. This will allow to overwrite settings in `preConfig`,
using `settings` option.
When `cfg.package` is already wrapped, and wrapped without the
`ExtensionSettings` key set, this would always add that key, even if its
value was blank. This would result in `cfg.finalPackage` being a
functionally-identical, but differently-input-addressed package. This is
generally undesirable as it may result in multiple derivations being
built, and also if the value of `cfg.package` is expected to be
unchanged by the user (e.g. because they want it to be consistent
between NixOS and HM configuration).
Add a test to ensure this does not regress in the default case. Only
test on newish stateVersion since the logic for `isWrapped` differs on
older versions.
Using a fixed application name in the salt for the search engine name
hash can break with minor branding changes. For example, LibreWolf 127
used the application name "LibreWolf", but in version 128 it is
"Firefox".
The proper name can be found in about:support -> Application Basics.
Because it doesn't have to be related to the product name visible in
most of the browser (for example in the window title and help menus),
we shouldn't rely on cfg.name for that.
The application name can be read from lib/*/application.ini and we can
use that if the browser was installed via Home Manager. If not, we can
fall back to cfg.name.
The lastUserContextId value should match the highest context ID from
the containers set in a given profile. This update ensures that this
always is the case.
Adds support for Firefox forks by introducing methods that create
generic configs and options. Additional configs and options can be
added in separate modules.
