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:
parent
5e9215b2cf
commit
316601db6c
2 changed files with 13 additions and 9 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue