[Feature] Support preconfiguration via Policy continued - #14422

I will be happy to provide a commit for nix dirvation for testing before merging remove that commit.

CC @alexanderby @darkreaderdev for review.

_{Aight, here we go to wait another year here}

dw I will ping those people every month, because this just can't be waited to be reviewed. And nix users have a default.nix to use for testing.

I won't touch anything here but I can request review from Alexander - so one more ping will be sent to him. 😉

Just FYI, there's a typo in default.nix. overrideAtrs should be overrideAttrs.

Also, I can't get the default.nix to work on my machine, so I am looking forward to when this gets merged!

It seems Home Manager added extension settings through programs.firefox.profiles.<name>.extensions.settings.<name>.settings, which works without policy support.

This setting only supports storage.local, so syncSettings = false is required.

"addon@darkreader.org".settings = {
  syncSettings = false;
};

Plus, it only works if you installed extensions with programs.firefox.profiles.<name>.extensions.packages and not with programs.firefox.policies (for that this PR is needed).

What's going on with this PR @alexanderby? It's fine if you aren't interested in merging this, but could you please let us know one way or another?

Just FYI, there's a typo in default.nix. overrideAtrs should be overrideAttrs.

Also, I can't get the default.nix to work on my machine, so I am looking forward to when this gets merged!

Fixed.

Thanks for fixing that issue, @eveeifyeve !

Also, yes, I’d love to see this merged. As @waltmck said, are there any updates on this @alexanderby ?

Thanks ☺️

Would be great to see this merged...

Would be great to see this merged...

I think the only issue with this pr is the nix file, but I am not sure still waiting on @alexanderby response.

@voronind-com 's comment aged well...

Aight, here we go to wait another year here

In all seriousness, I'd love to see this merged as well.

Thanks for the contribution and for keeping the discussion active.

To clarify why this PR has not moved forward: adding declarative preconfiguration via policies (storage.managed) introduces several lifecycle, state, and maintenance challenges:

1. Lifecycle and State Overwriting:
   Implementing preconfiguration requires resolving when policy values are consumed:

   • If applied only on initial install (onInstalled), future updates to the declarative policy files will not sync, leading to confusion and bug reports.
   • If evaluated on startup (onStartup), it risks overwriting runtime user adjustments made via the popup unless a complex dirty-checking and state reconciliation layer is introduced.

2. Schema Evolution and Validation:
   Dark Reader's internal settings schema can change across versions. Parsing external unvalidated policy JSON requires strict validation, fallback routines, and schema migrations to prevent extension crashes or corrupted local storage.

3. Maintenance and Testing Overhead:
   We do not have CI pipelines, automated tests, or staging environments to validate enterprise policies across declarative setups (like Nix / Home Manager) and standard OS policy engines. We cannot reliably prevent regressions across release cycles.

4. Core Scope and Bandwidth:
   Our primary focus remains on the dynamic theme generation engine, performance, DOM parsing stability, and browser compatibility. Supporting external preconfiguration schemes introduces continuous maintenance debt for a niche deployment scenario.

Because of this overhead, we are hesitant to expand the configuration surface area without dedicated long-term maintainers for policy-based deployment workflows.

@alexanderby Could you confirm this point of view so we can make a final call here?

If evaluated on startup (onStartup), it risks overwriting runtime user adjustments made via the popup unless a complex dirty-checking and state reconciliation layer is introduced.

For the record, that's the model I would want (overwriting runtime user adjustments), and what we use in all my Firefox Extensions Declarative forks, including our Dark Reader fork.