[Mozilla Enterprise] Downgrade Protection and Profile Per Installation in Firefox 68

[Stephen Dowdy]

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   -  sdowdy at ucar.edu        -  http://www.ral.ucar.edu/~sdowdy/