This is the same as the original patch, except for the added localization notes around the necessarily duplicated strings.
Differential Revision: https://phabricator.services.mozilla.com/D158800
It's important that this shortcut exists to avoid https://bugzilla.mozilla.org/show_bug.cgi?id=1762994. We were creating it in the installer to avoid first run I/O, with a fallback at runtime to catch zip builds and updates. Due to some of this code being in the installer and some of it in the browser, we ended up with two different strings. Unfortunately, this has resulted in a bug where we sometimes create two private shortcuts. This happens in at least two cases:
1) A localization has only translated one of those strings -- in which case we get an en-US string and a localized string
2) A localization has translated the strings differently -- in which case we get two localized, but slightly different, stings
Since the installer creation of the shortcut is an optimization, and the first run I/O is now on a background thread anyways, let's just get rid of the installer shortcut rather than trying to come up with a more complex fix for this.
Differential Revision: https://phabricator.services.mozilla.com/D157348
The problem here ended up being that we lose the value of `AddTaskBarSC` once ExecCodeSegement is called -- which we do anytime we try to set ourselves as the default if the installer was run elevated.
Differential Revision: https://phabricator.services.mozilla.com/D151291
This patch starts pinning Firefox to the Taskbar by default on all supported Windows versions. The main addition here is a port of our existing taskbar pinning code for modern Windows 10 & 11 versions to an NSIS plugin (compiled version also included).
After discussion with a few stakeholders, we also decided that we will never pin during an update on Windows 10 or 11. (Arguably we could stop on Windows 7 & 8 as well - but I don't really see any harm in carrying forward our pre-existing behaviour there.) With this in mind, I dropped all the second pinning attempt code (which was only ever enabled for Windows 10).
Differential Revision: https://phabricator.services.mozilla.com/D148288
This patch starts pinning Firefox to the Taskbar by default on all supported Windows versions. The main addition here is a port of our existing taskbar pinning code for modern Windows 10 & 11 versions to an NSIS plugin (compiled version also included).
After discussion with a few stakeholders, we also decided that we will never pin during an update on Windows 10 or 11. (Arguably we could stop on Windows 7 & 8 as well - but I don't really see any harm in carrying forward our pre-existing behaviour there.) With this in mind, I dropped all the second pinning attempt code (which was only ever enabled for Windows 10).
Differential Revision: https://phabricator.services.mozilla.com/D148288
This fixes a bug where pinning a Private Browsing window to Taskbar with the windows context menu item pins regular Firefox instead. This happens because Windows cannot find an appropriate shortcut (presumably by looking for one with the right AUMID), and ends up creating its own instead -- with almost entirely incorrect metadata.
With this, we'll be creating one at a few points (if it doesn't already exist):
* Installer - for new installs
* Post-Update - to make sure we get one when people update to the first version where we pref this on
* Startup idle - for zip installs, and to handle any other possible case where the shortcut doesn't exist
Until we enable separation of Private Windows by default I've pref'ed off this behaviour (otherwise a user may pin the shortcut to the Taskbar, but the app will launch into a different icon).
Differential Revision: https://phabricator.services.mozilla.com/D147702
This patch starts pinning Firefox to the Taskbar by default on all supported Windows versions. The main addition here is a port of our existing taskbar pinning code for modern Windows 10 & 11 versions to an NSIS plugin (compiled version also included).
After discussion with a few stakeholders, we also decided that we will never pin during an update on Windows 10 or 11. (Arguably we could stop on Windows 7 & 8 as well - but I don't really see any harm in carrying forward our pre-existing behaviour there.) With this in mind, I dropped all the second pinning attempt code (which was only ever enabled for Windows 10).
Differential Revision: https://phabricator.services.mozilla.com/D148288
about:newtab#asrouter actually depends on the ability to be able to write to postSigningData at the moment, so this will break that in any circumstance where the running Firefox cannot write to the installation directory. This code is only used for dev & qa testing though, and I've been told this is OK (and we may change how it works to avoid writing the file at all).
Differential Revision: https://phabricator.services.mozilla.com/D144167
This was simply an oversight on my part: I didn't appreciate that
freshly introduced ProgIDs need to be added or updated unconditionally
in PostUpdate.
I've tested this by copying the fresh `helper.exe` into an existing
installation directory, running `uninstall\helper.exe /PostUpdate`
manually, verifying the expected ProgIDs exist in HKCR, and then
verifying that "Make default" within Firefox succeeds.
At some point we should do the same for `FirefoxHTML-*` and
`FirefoxURL-*`, but this patch should be uplifted to Beta 100 and I
don't want to introduce additional risk.
Differential Revision: https://phabricator.services.mozilla.com/D143661
The new icon is not channel-specific, but I've kept it in branding
since it's possible that we'll distinguish in the future.
Differential Revision: https://phabricator.services.mozilla.com/D142396
This is simply the mechanics of s/FirefoxHTML-.../FirefoxPDF-.../. We
need this to alter the description ("Firefox PDF Document") and, in
subsequent commits, the display icon.
Generally I tried to keep alphabetical ordering: FirefoxHTML-...,
FirefoxPDF-..., FirefoxURL-...; and I generally tried to use the '-'
suffix to disambiguate the older FirefoxHTML from the newer suffixed
FirefoxHTML-... form.
Differential Revision: https://phabricator.services.mozilla.com/D142302
The `-osint` flag is used as the signal that Windows is invoking
Firefox to handle a file type or protocol. The `-osint` flag was
introduced in order to mitigate security breaches due to poor argument
quoting (by consumers invoking Firefox); to use it for this new
purpose, it must be preserved for downstream consumers to react to.
Alternately, some marker of the flag could be maintained. Since the
flag needs to transit through the launcher process, I've elected to
simply not strip it as we validate command lines, and to accommodate
it further downstream. (It looks like Thunderbird already
accommodates `-osint`: see
https://searchfox.org/comm-central/rev/3e8f926de9ea09945b237177eb6d489c70318f0e/mail/components/MessengerContentHandler.jsm#568.)
The telemetry in this patch achieves two purposes. The first is to
count the number of times Firefox is invoked to handle a registered
file type or protocol: for this, a new keyed uint scalar was added.
File types start with a ".", just like on Windows; protocols
(equivalently, the schemes used to identify them) do not start with a
".".
The second is to identify times when Firefox is launched (i.e., it was
not already running) to handle a registered file type or protocol.
This generalizes the existing `os.environment.launch_method`,
introducing `os.environment.launched_to_handle` and
`os.environment.invoked_to_handle` string scalars, which record the
file type or protocol.
The command line state `STATE_INITIAL_LAUNCH` is used to discriminate
launching from invoking.
Differential Revision: https://phabricator.services.mozilla.com/D132288
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
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
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
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
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
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
Also fix two other installer problems that were getting missed because of this:
one build error in PostUpdate and one use of an uninitialized value in the
installer, causing it to record that it had not registered the task when it had.
Differential Revision: https://phabricator.services.mozilla.com/D67915
CLOSED TREE
Backed out changeset 85ea1d36da66 (bug 1515451)
Backed out changeset 779bc1fa07ae (bug 1515451)
Backed out changeset 0c6771b60b76 (bug 1515451)
Allow Firefox to be specified as a handler for 'mailto:' urls on Windows.
Re commit of Phabricator differential D2247 -- that's too old to be reused.
Differential Revision: https://phabricator.services.mozilla.com/D65438
Bug 1295542 added empty chrome.manifest files to prevent malware from abusing
them. This workaround is no longer necessary because Firefox stopped reading
chrome.manifest outside omni.ja since bug 1543761.
Differential Revision: https://phabricator.services.mozilla.com/D55954
The previous patch didn't work because the helper running as the unelevated
user is the only one that can read the pref out of its user registry hive,
which is where Firefox has to write it, but then since it's limited it can't
write to either the shortcut log or to HKLM. So everything has to happen in
HKCU so that the unelevated helper can both read and write where it needs to
read and write to.
Differential Revision: https://phabricator.services.mozilla.com/D53113
My initial idea of using the shortcuts log to store this information didn't
work out because the helper, when run by an updater which was run by the
maintenance service, doesn't get write permissions on that file.
Differential Revision: https://phabricator.services.mozilla.com/D52276
