* New installs should always have launcher process telemetry enabled by default
(since it is opt-out telemetry).
* Upgrades do a reset of the force-disabled launcher state, as that state might
have been set by SHIELD but is no longer desired in 68.
* We add the `|Telemetry` registry value to the list of values to be removed at
uninstall.
Differential Revision: https://phabricator.services.mozilla.com/D29544
--HG--
extra : moz-landing-system : lando
The idea here is that the installer always disables by default, but then
Firefox itself later re-enables when the appropriate pref is turned on.
I also added a check for the third launcher process registry key (|Image)
since we really only want to do this when all three registry values are
nonexistent.
Differential Revision: https://phabricator.services.mozilla.com/D20620
--HG--
extra : moz-landing-system : lando
Fix for warnings in uninstaller.nsi for unknown variable AddTaskbarSC by adding
the variable to the nsi file rather than adding a version of MigrateTaskBarShortcut
specific to the uninstall procedure
Differential Revision: https://phabricator.services.mozilla.com/D18629
--HG--
extra : moz-landing-system : lando
This code hasn't been needed in quite a long time at this point and it should be removed.
Differential Revision: https://phabricator.services.mozilla.com/D17657
--HG--
extra : moz-landing-system : lando
This patch also removes the last vestiges of the old architecture dropdown
structure, and removes a use of GetBinaryTypeW because it doesn't seem to
return a useful result for any ARM ISA.
Differential Revision: https://phabricator.services.mozilla.com/D14811
--HG--
extra : moz-landing-system : lando
This Image File Execution Option is required for firefox.exe and
plugin-container.exe because the multi-threaded loading interferes
with the chromium sandbox.
This change applies to Windows only.
Firefox will need to migrate the directory from the old location to the new location. This will be done only once by setting the pref `app.update.migrated.updateDir2.<install path hash>` to `true` once migration has completed.
Note: The pref name app.update.migrated.updateDir has already been used, thus the '2' suffix. It can be found in ESR24.
This also removes the old handling fallback for generating the update directory path. Since xulrunner is no longer supported, this should no longer be needed. If neither the vendor nor app name are defined, it falls back to the literal string "Mozilla".
The code to generate the update directory path and the installation hash have been moved to the updatecommon library. This will allow those functions to be used in Firefox, the Mozilla Maintenance Service, the Mozilla Maintenance Service Installer, and TestAUSHelper.
Additionally, the function that generates the update directory path now has extra functionality. It creates the update directory, sets the permissions on it and, optionally, recursively sets the permissions on everything within.
This patch adds functionality that allows Firefox to set permissions on the new update directory on write failure. It attempts to set the permissions itself and, if that fails and the maintenance service is enabled, it calls into the maintenance service to try from there. If a write fails and the permissions cannot be fixed, the user is prompted to reinstall.
Differential Revision: https://phabricator.services.mozilla.com/D4249
--HG--
rename : toolkit/mozapps/update/updater/win_dirent.cpp => toolkit/mozapps/update/common/win_dirent.cpp
rename : toolkit/mozapps/update/tests/unit_aus_update/cleanupSuccessLogMove.js => toolkit/mozapps/update/tests/unit_aus_update/updateDirectoryMigrate.js
extra : moz-landing-system : lando
Also remove a useless line that looks like some debugging code I accidentally left in.
Differential Revision: https://phabricator.services.mozilla.com/D5059
--HG--
extra : moz-landing-system : lando
At least in Win10, Firefox is not an option to configure as a mailto handler.
Differential Revision: https://phabricator.services.mozilla.com/D2247
--HG--
extra : moz-landing-system : lando
We occasionally get reports of UI unresponsiveness immediately following the
download phase of the stub installer. The longest operation that runs on the
main thread during this phase is validating the code signature of the full
installer. This patch moves that work (which is done in a native NSIS plugin)
to a separate thread. Hopefully this helps resolve the hangs.
I've also converted the build files for the plugin from Visual C++ 6 to 2017,
just to avoid the inconvenience of needing to pull up VC6 to build it.
MozReview-Commit-ID: CKje2a8M62i
--HG--
extra : rebase_source : ec9a11268eed3c4f9e0783532b0e910289e809f9
I'm also adding a "StartMenuShortcut" option as an alias for "StartMenuShortcuts",
because I could not stop leaving off the 's' while testing this patch, so I
figure I'm not the only one making that mistake and getting frustrated.
MozReview-Commit-ID: Fdsc6CTBJr4
--HG--
extra : rebase_source : c57295e0936b6721bc75d6f11f33bad6691b96de
The uninstaller was being built as a side-effect of building `setup.exe`. In
Bug 1385227, that was moved from "somewhere" to part of the windows installer
packaging, which happens after the zip and mar are generated. Since the
installer we ship is actually repackaged from the zip[1], we stopped shipping
translated uninstallers.
This changes things around so that the uninstaller gets translated:
- Explicitly build the uninstaller as part of the L10n repack step.
- Use the same logic to build the installer locally as we do to create the ones
we ship.
[1] Except on Thunderbird
Differential Revision: https://phabricator.services.mozilla.com/D672
--HG--
extra : rebase_source : 05fe935c1d2a9fbfeef786819bfe5913ed8ef862
extra : source : d6bf22099e2195dcb64c3c3d7700d3edd0850a3a
The uninstaller was being built as a side-effect of building `setup.exe`. In
Bug 1385227, that was moved from "somewhere" to part of the windows installer
packaging, which happens after the zip and mar are generated. Since the
installer we ship is actually repackaged from the zip[1], we stopped shipping
translated uninstallers.
This changes things around so that the uninstaller gets translated:
- Explicitly build the uninstaller as part of the L10n repack step.
- Use the same logic to build the installer locally as we do to create the ones
we ship.
[1] Except on Thunderbird
Differential Revision: https://phabricator.services.mozilla.com/D672
--HG--
extra : rebase_source : 2b28b9ff7196d12f4a188c8dddf750b9a5efac5b
extra : histedit_source : 9bc28891950ae8c226cfdefef6f8121ce0b51f58
Currently, clicking the close button or otherwise trying to exit the Windows
stub installer always ends up canceling the installation. This patch prompts
the user to either continue or cancel the installation.
MozReview-Commit-ID: 4KMgCcyjTnv
--HG--
extra : rebase_source : 0c0636c9c02fabd32df37471033d8e847caea5d3
