Don't regenerate the firefox config if a part of the version changed
that isn't the major version as this would just lead to needless
regernations and slightly delayed startup.
Split the #mainPopupSet CSS rule to an extra file
popups.before-ff-108.css, and adjust autoconfig.js to skip that file if
firefox is newer than >= 108.
It's pretty hard to get the code right in this autoconfig script, as the
only feedback you get is whether the script crashed or not. Add a
logging function to make it easier.
With the current implementation, `userChrome.css` and `userContent.css`
are effectively replaced on a package update, but the session still uses
the previous version.
Triggering a restart as soone as those files are updated ensures the
latest version will be used immediately.
Now that there's a nice about:home page, show it in new tabs too instead
of the weird looking blank page. Set this in autoconfig.js instead of
policies.json, so it can be overridden by the user via settings page.
In the Tor browser user agent, the "geckotrail" part has been changed.
Apparently following an upstream change in Firefox:
> From Firefox 10 on mobile, geckotrail is the same as firefoxversion.
Note: I'm simply running latest Tor browser on Android and visit
websites showing the user agent to figure out the latest one. I tried to
figure it out from the source code once, but didn't find a place where
it could be looked up trivially (since it gets built of multiple
components etc.).
Related: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox
Preferences set with `pref()` can be changed by the user, but they're
then reset on each Firefox startup.
As users may want a different UA and keep it persistent, we should set
the default value with `defaultPref()` instead. This requires moving the
preference to the autoconfig file though, as `defaultPref()` isn't
recognized in the main config file.
Firefox can run an autoconfig Javascript on startup, which can be used to
install and update userChrome.css, both when creating a new profile and
using a pre-existing one.
This removes the need for a wrapper script and related complications
(changes to $PATH, different processing for new and pre-existing
profiles...)
Co-Authored-By: Oliver Smith <ollieparanoid@postmarketos.org>
