firefox: support setting search engine & adding custom engines

[kira-bruneau]

Description

With this change, it's now possible to configure the default search engine in Firefox with programs.firefox.profiles.<name>.search.default and add custom engines with programs.firefox.profiles.<name>.search.engines.

It's also recommended to enable programs.firefox.profiles.<name>.search.force = true since Firefox will replace the symlink for the search configuration on every launch, but note that you'll loose any existing configuration by enabling this.

Here's an example of how I'm using this in my home-manager config: https://gitlab.com/kira-bruneau/home-config/-/blob/028c1a50c82f8cad2be3d6693e6c53c67bf7e7c2/package/firefox/default.nix#L9-93.

NOTE: The hash verification is only required for custom search engines, it's ignored when setting your default engine to a builtin engine, but I set this up to still generate the hash anyway to be consistent with Firefox.

Closes #2318 @pshirshov

Checklist

• [x] Change is backwards compatible.

• [x] Code formatted with ./format.

• [x] Code tested through nix-shell --pure tests -A run.all.

• [x] Test cases updated/added. See example.

• [x] Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

~- If this PR adds a new module~

• [x] Added myself as module maintainer. See example.

• [x] Added myself and the module files to .github/CODEOWNERS.

[pshirshov]

Excited to see this, thank you! Any chance it can be merged soon?

[kira-bruneau]

I decided to rename the enable option to force and make it optional, so it's clearer that it isn't "enabling" search, but overriding the existing search config that Firefox writes.

[pshirshov]

Is there any blocker for this to be merged? :(

[pshirshov]

@peterhoeg

[pshirshov]

@rycee , sorry about bothering you, but could you have a look at this please?

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/firefox-search-engine-shortcuts/22177/5

[pshirshov]

@Atemu , @ncfavier : any chance you may accept it?

[pshirshov]

@kira-bruneau seems like the P/R doesn't work on macOS:

error: Package ‘mozlz4a-2018-08-23’ in /nix/store/qr489cwcx2l5b9m234g5ipqxan0mr7fd-source/pkgs/tools/compression/mozlz4a/default.nix:27 is not supported on ‘x86_64-darwin’, refusing to evaluate.

Though I don't see anything linux-specific in the python script (formula, script), do you think you may just incorporate that script into your PR?

[pshirshov]

https://github.com/NixOS/nixpkgs/issues/196018

[pshirshov]

https://github.com/NixOS/nixpkgs/pull/196021 - I guess that may help

[Atemu]

@pshirshov neither of us are maintainers here; we only provided feedback on the code.

[pshirshov]

@rycee : please...

[rycee]

Thanks! Fixed a few minor issues and merged to master now.

I think some of the code could benefit by having more let bindings to make it a bit more understandable, see e.g. the definition of orderedEngineList, but it's OK for now.

[pshirshov]

To be honest, even as it is it's totally understandable and it's a real game changer. Many thanks!

[rycee]

Indeed, this is a very nice feature and @kira-bruneau did a great job implementing it! So, I hope my comment above does not seem too negative, it was meant purely as constructive criticism.

[kira-bruneau]

@rycee Yeah... I was worried it was too messy / hard to follow :sweat_smile:, but there's also just a lot going on to get this to work. I'll try to clean it up some more. Would it make sense to try to split this into a separate file?

[rycee]

@kira-bruneau No need for a separate file, I think. It seems to me the thing that would help readability the most in this case is "naming things".

For example, instead of having, loosely modeled on orderedEngineList,

imap (i: x: long expression) xs ++ map (y: long expression) (expression)

one could try doing something like

let
  descriptiveName1 = i: x: long expression;
  descriptiveName2 = y: long expression;
  descriptiveName3 = expression;
in
  imap descriptiveName1 xs ++ map descriptiveName2 descriptiveName3

the long expressions themselves may benefit from let bindings, in which case the variable could be placed either within the function definition or on the same level as descriptiveNameX. Typically I would move the definition out of the function unless it uses a function argument.