Windows MSIX packages support a finite set of locales: see
https://docs.microsoft.com/en-us/windows/uwp/publish/supported-languages.
This patch encodes that list in
browser/installer/windows/msix/msix-all-locales. Two ad-hoc
modifications were necessary: removing 'sr*' (Serbian) and 'uz*'
(Uzbek) in order for the resulting MSIX packages to install.
We distribute all of the langpacks supported by the release channel in
our MSIX, which is encoded in browser/locales/all-locales. But we
only advertise support in the App manifest for the intersection of
that set and the set of locales supported by Windows.
We do so to avoid the following issue. Suppose a user manually
installs a langpack that is not supported by Windows, and then updates
the installed MSIX package. MSIX package upgrades are essentially
paveover installs, so there is no opportunity for Firefox to update
the langpack before the update. But, since all langpacks are bundled
with the MSIX, that langpack will be up-to-date, preventing one class
of YSOD.
Differential Revision: https://phabricator.services.mozilla.com/D126175
1. $LocalAppData behavior changes in NSIS 3.02, previously it always
used CSIDL_LOCAL_APPDATA but it now depends on context, work around
that by directly calling SHGetSpecialFolderPathW.
2. Refactor several other calls to SHGetSpecialFolderPathW for
CSIDL_COMMON_APPDATA and CSIDL_PROGRAMS.
3. Remove broken default path fallback to $APPDATA. I was in this
code for 1. and realized it hadn't worked properly in the full
installer since bug 367539, and it must have never worked in the stub.
4. Remove unused CleanUpdateDirectories and DeleteRelativeProfiles
macros rather than trying to fix them.
Differential Revision: https://phabricator.services.mozilla.com/D125490
When relanding Bug 1709697, all of the icons ended up as 0-byte files.
I can't explain this; it's hard to achieve this with a rebase. We
regenerate `Resources.pri` following the instructions in the
documentation.
This commit also moves to represent the package as "Mozilla Firefox",
which is consistent with how unpackaged versions appear in the Windows
UI. In the start menu, the application continues to be represented as
"Firefox" (no "Mozilla" vendor).
Finally, this commit also differentiates "Firefox Beta" from "Firefox"
in a few select places (while not changing branding and iconography).
Differential Revision: https://phabricator.services.mozilla.com/D122411
Installing the Nightly MSIX packages, signed with Mozilla's Nightly
key, yields an error: "Error in parsing the app package." Unpacking
with `makeappx.exe` yields:
```
MakeAppx : error: Error info: error 8007000B: The app manifest publisher name (CN=Mozilla Corporation) must match the subject name of the signing certificate (CN=Mozilla Corporation, OU=Firefox Engineering Operations, O=Mozilla Corporation, L=Mountain View, S=California, C=US).
```
Previously, we allowed just the `CN` to vary; in this patch we make
the publisher be the entire publisher subject, and we update the
publisher details in the task definitions.
Differential Revision: https://phabricator.services.mozilla.com/D121896
Allow for downstream projects such as Thunderbird to set different GUIDs for
AccessibleHandler to avoid clashes when both applications are installed.
The GUIDs themselves can be defined in confvars.sh or in branding/configure.sh
depending on the specific needs of the application. Fallback GUIDs are in
old-configure.
Differential Revision: https://phabricator.services.mozilla.com/D118124
The goal is to make it easier for admins to have a generic way to
locate Firefox for uninstall, without needing to know the target
version to uninstall. The version in the `DisplayName` is extraneous:
it's in the `DisplayVersion` field, and users can see it when you
click on it in "Add/Remove Programs". Automated consumers may prefer
to read the `Comments` field of the Firefox uninstall data instead,
which remains identical to the `DisplayName` before this change.
Differential Revision: https://phabricator.services.mozilla.com/D116648
FILE_FLAG_DELETE_ON_CLOSE had the wrong semantics, rendering the lock
file unusable after it had been closed once.
Delete the lock file in the uninstaller as a simple alternative (given that
the lock file is not in a temporary location on Windows).
For a test I returned to the older form of
test_backgroundtask_update_sync_manager which initially exposed the issue:
It expects the background task to be able to detect the xpcshell instance
after running resetLock, which failed before this fix.
I also extended the original updateSyncManager test to run the second
copy twice, which also catches the issue.
Differential Revision: https://phabricator.services.mozilla.com/D109565
For all channels, this commit:
1. stops registering the ftp protocol handler at install time;
2. actively unregisters the ftp protocol handler at postupdate time;
3. stops unregistering the ftp protocol handler at uninstall time.
The rationale for 3) is that by the time a `helper.exe` with this
change is in place, the `postupdate` step has already run and
unregistered the ftp protocol handler.
Differential Revision: https://phabricator.services.mozilla.com/D104735
* Puts the docs in order, so that contributors aren't jumping to the
middle of the page to install system tools, then back to the top to
clone Firefox.
* Removes docs on MacPorts since it's being removed in bug 1688263.
* Removes step to manually install brew packages since that happens
automatically in bootstrap now.
* Simplifies mercurial installation docs
* Removes unnecessary mozconfig-tweaking instructions
* Removes almost-always-unnecessary DEFINE and troubleshooting
information.
Differential Revision: https://phabricator.services.mozilla.com/D102974
I'm keeping the --enable-update-agent config option and the corresponding
MOZ_UPDATE_AGENT config flag and define, as these should still be useful.
As we never shipped this there is no need to keep anything around to
clean up the scheduled tasks.
Differential Revision: https://phabricator.services.mozilla.com/D99574
It's not 100% clear that this has any effect -- it might be that the
string is case insensitive -- but in any case let's keep our source
code uniform.
Differential Revision: https://phabricator.services.mozilla.com/D94774
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
The `clobber` targets are superseded by `mach clobber`, so we don't need them for any reason. The `clean` target is meant to get you to a post-`configure` state, but it doesn't really work, and if it's necessary for you to be in that state for some reason you can just clobber and re-`configure`, so it doesn't seem worth it to get it working again. Instead, delete all of them. Also delete `everything` which is not useful when `clobber` doesn't exist.
Differential Revision: https://phabricator.services.mozilla.com/D93514
The PostUpdate task must always be called as the unelevated user, even if we didn't use the service, in order to ensure that we register the WDBA. Additionally, the PostUpdate task should always be run synchronously so that the elevated and unelevated PostUpdate tasks are guaranteed to run in order. This is important since the elevated PostUpdate unregisters the task and the unelevated PostUpdate re-registers it.
Differential Revision: https://phabricator.services.mozilla.com/D87509
Since bug 1510494, when the maintenance service is used, we create update log
and status files inside the service directory and then move them into the
regular update directory when finished. However, the directory those temp
files are stored in did not get added to the uninstallers, so it doesn't
get removed as it should.
This patch has two parts. First, the Firefox uninstaller now removes any log
files created for the installation it's uninstalling (there is only one
directory and the files for different installation are differentiated by name).
Second, the maintenace service uninstaller, when it gets run by the uninstaller
for the last copy of Firefox on the system, removes the UpdateLogs directory
itself, provided it is empty, which is should be at that point since all
installations have been removed and have cleaned up their own files.
Differential Revision: https://phabricator.services.mozilla.com/D85074
Detect a profile for the installation, if found offer refresh on welcome page:
- Replace text
- Add help link and button
Add a different prompt to close the browser for refresh.
When leaving the welcome page:
- via help link, launch a URL
- via Refresh button, launch Firefox with the necessary args
Add utility functions to launch the link and Firefox.
Remove the UN_CONFIRM_CLICK label and hide the subheading, this was an
addition to the design. Move down UN_CONFIRM_PAGE_TITLE to fill in the space.
Move the check for the install-specific profile to common.nsh from stub.nsi,
wrapped in stack ops to save regs and with _MOZFUNC_UN for uninstaller compat.
Move InitHashAppModelId to just after un.UninstallUnOnInitCommon (which sets
$INSTDIR correctly), so AUMID would be available in un.PreWelcome. I don't
think there's anything else that would change $INSTDIR in the uninstaller
so this should be ok.
Unrelated but adjacent cleanup: Remove inappropriate use of _MOZFUNC_UN
in CopyPostSigningData.
Differential Revision: https://phabricator.services.mozilla.com/D76435
This also requires removing the registry value cleanup from the unregister-task
command and adding a new uninstall command which removes both the task and the
registry values, because this patch now runs unregister-task during updates to
remove the task before re-adding it, and that needs to leave the registry alone.
Differential Revision: https://phabricator.services.mozilla.com/D76354
For builds with ftp disabled (see below), this commit:
1) stops registering the ftp protocol handler at install time;
2) actively unregisters the ftp protocol handler at postupdate time;
3) stops unregistering the ftp protocol handler at uninstall time.
The rationale for 3) is that by the time a `helper.exe` with this
change is in place, the postupdate step has already run and
unregistered the ftp protocol handler. This could, of course, fail,
and a fallback would be nice. However having a guarded block, just
like everywhere else, will make it much more likely that the complete
removal of the ftp protocol will also cull the uninstall code. I
prefer making the latter cleanup more likely to be complete.
The bool pref that disables ftp functionality is
"network.ftp.enabled", and at this time that defaults to
!NIGHTLY_BUILD. In the {un}install process, there's no way to inspect
that pref dynamically, so we use !NIGHTLY_BUILD as well.
This opens a race window for developers to change the pref default
without changing the {un}install conditional at the same time. It
would be possible to close that window by introducing a new configure
subst but given the imminent removal of the ftp protocol entirely it
doesn't seem necessary.
Differential Revision: https://phabricator.services.mozilla.com/D74503
Comparing to .webp, we already do two of three things needed. This
arranges the last thing: registering the file association.
Differential Revision: https://phabricator.services.mozilla.com/D76244
James Teh
Riya
Jon Bauman
Nick Alexander
Adam Gashlin
Narcis Beleuzu
Rob Lemley
Kirk Steuber
Gabriele Svelto
Mitchell Hentges
Masatoshi Kimura
Ricky Stewart
Bogdan Tara
Dorel Luca
Sylvestre Ledru
Molly Howell
Michael Kaply
Sarah Bird