On 6/24/19 2:39 PM, Mike Kaply wrote:
Environment variables will be available in Firefox 68 to disable both features
and we are assessing whether this will be enough for ESR users to maintain
compatibility with their custom deployment configurations.
It would be great if you could let us know of specific issues related to these
features that an environment variable would not allow addressing.
Mike,
By "...downgrade protection...prevent users from hitting profile corruption issues
when switching between different versions/channels of Firefox.", it seems that the
historical compatibility in netscape/firefox for profiles is gonna get problematic. (i
can't recall ever in the past (from netscape 1.x to now), where a profile corruption
occured from going forward/backward in versions on the same profile)
I do usually keep version "N-1" available for users if they find an issue they
can't workaround, so :
/usr/local/firefox-67.0.4 (symlinked as /usr/local/firefox/ default
version)
/usr/local/firefox-67.0.3
/usr/local/firefox-60.7.2esr (symlinked as /usr/local/firefox-esr default
ESR version)
/usr/local/firefox-60.7.1esr
So, i guess if someone does drop back a version, they could get some grief.
(in actuality, i don't think anybody's actually used a previous version)
I had to go back to creating a wrapper script and a symlink for the firefox-bin
in my 'Install-Firefox' script (see below):
This is pretty ugly,but at least there's now a supported method to do this.
It woulda been easier if i coulda stuffed something in 'mozilla.cfg' or
${APPDIR}/defaults/pref/site.js - which i already drop into the extraction
directory. (and i believe is read prior to users' profile, but could be wrong)
*BUT*, others also note that having a variable/preference named *LEGACY* (something else
recently had a pref with "legacy" in it, but i don't recall) doesn't give us/me
good feelings about the level of future support for it.
---------------------------------------------------------------
(pkg_name = "firefox", pkg_ver = 67.0.4, etc)
mv ${common_root}/local/${pkg_name}-${pkg_ver}/${pkg_name} \
${common_root}/local/${pkg_name}-${pkg_ver}/${pkg_name}.real
cat > ${common_root}/local/${pkg_name}-${pkg_ver}/${pkg_name} <<"EOF"
#!/bin/sh
# Ref:
https://blog.nightly.mozilla.org/2019/01/14/moving-to-a-profile-per-install-architecture/
# Ref:
https://github.com/andir/nixpkgs/commit/082ed38cb11b1a53cc5583ea44fdd8e90500e43b#diff-d546c0cc4fa5e6ccb4772cdeab3c38a8
# Ref: https://bugzilla.mozilla.org/show_bug.cgi?id=1528082
# Ref: https://phabricator.services.mozilla.com/D35249 (looks like fix is
gonna be MOZ_LEGACY_PROFILES=1 :-(
...
realpath="$(readlink -e $0)"
realpath="${realpath%/*}"
export SNAP_NAME="firefox" # This is an unintended HACK!!!
--> export MOZ_LEGACY_PROFILES="1" # This is supposedly the new envvar to
keep profiles
# Note that 'firefox' exe is a front-end DLL/ld.so loader that ultimately
calls ${0}-bin, so we need firefox.real-bin also..
exec ${realpath}/firefox.real "$@"
EOF
chmod 555 ${common_root}/local/${pkg_name}-${pkg_ver}/${pkg_name}
ln -sf firefox-bin
${common_root}/local/${pkg_name}-${pkg_ver}/${pkg_name}.real-bin
---------------------------------------------------------------
--stephen
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - [email protected] - http://www.ral.ucar.edu/~sdowdy/
_______________________________________________
Enterprise mailing list
[email protected]
https://mail.mozilla.org/listinfo/enterprise
To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise
or send an email to [email protected] with a subject of
"unsubscribe"
