zen: write userChrome.css again alongside zen-theme.css

The watcher not landing left Zen with no theme at all. Keep the startup copy
so the floor is the old behaviour, and let the watcher fight for the live
update on top.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
rope 2026-08-31 19:35:08 +01:00
parent 5e9215b2cf
commit 316601db6c
2 changed files with 13 additions and 9 deletions

View file

@ -11,10 +11,11 @@ let
# that is what makes a `theme-apply` switch land in a running Zen
# (settings/theming.nix writes that file on every switch).
#
# userChrome.css can't stay as a safety net: nsIStyleSheetService user
# sheets are ordered BEFORE the profile's userChrome.css, so a leftover copy
# would outrank every sheet we register and pin Zen to whichever wallpaper
# was live at startup — the exact bug this fixes.
# theming.nix still writes userChrome.css too, so a broken watcher costs the
# live update and nothing else. Whether the watcher can win at all is the
# open question: nsIStyleSheetService documents its user sheets as ordered
# BEFORE the profile's userChrome.css, which would let the startup copy
# outrank every sheet we register.
#
# Everything here goes through Components.classes. The autoconfig sandbox is
# not a normal system-principal scope: `Services` is not a global in it, and