As a user sheet it sorted below userChrome.css and lost every !important to
the copy parsed at startup. Agent sheets sort above ua.css; @-moz-document
keeps that origin off web pages.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
wrapFirefox only copies the exe matching binaryName ("zen-beta"), but Gecko
execs lib/zen-bin-*/zen, a symlink into the unwrapped package. The app dir
resolved there, so mozilla.cfg and defaults/pref were never read.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fred.zenTheme.autoconfig / .cfg / .status say which of the three stages the
theme watcher reaches, using the one API autoconfig always has.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Firefox 62+ restricts mozilla.cfg to pref()/defaultPref(); Components was
undefined, so the watcher threw on its first line and so did its catch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
The autoconfig sandbox has no Services global, so the watcher threw before
registering anything. Go through Components.classes only, resolve ProfD per
pass, and record the result in fred.zenTheme.status.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gecko has no userChrome.css reload, so wrap zen with a mozilla.cfg script
that registers chrome/zen-theme.css through nsIStyleSheetService and
re-registers it under a cache-busting URI when its mtime moves.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
