Private browsing doesn't make sense for Thunderbird. Wrap the use of
$AddPrivateBrowsingSC to avoid breaking the installer build.
Differential Revision: https://phabricator.services.mozilla.com/D161340
This exists primarily to ensure that Enterprise installs can disable it (who also may disable private browsing by policy).
Differential Revision: https://phabricator.services.mozilla.com/D161207
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
I'm not certainly if it's possible to actually pin with all 3 of these logos (it may depend on Windows settings but also other aspects of our manifest?) -- but it should be harmless and futureproof to specify this option for all of them.
Differential Revision: https://phabricator.services.mozilla.com/D158510
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
Non-MSIX notifications are not removed when Firefox is uninstalled. To handled this we've added a new `uninstall` background task and extended `nsIWindowsAlertService` to deregister notifications on uninstall.
Differential Revision: https://phabricator.services.mozilla.com/D156625
Non-MSIX notifications are not removed when Firefox is uninstalled. To handled this we've added a new `uninstall` background task and extended `nsIWindowsAlertService` to deregister notifications on uninstall.
Differential Revision: https://phabricator.services.mozilla.com/D156625
This converges Windows native notification behavior across all installers to use the COM notification server.
This also fixes an issue where interacting with an MSIX notification opened a new window with new tabs correlated to the toast notification launch arguments. MSIX by default calls the application sending a notification with the provided launch arugments, which was an problem as we use launch arguments in the COM server to reconstruct the origin of a notification.
Differential Revision: https://phabricator.services.mozilla.com/D153538
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 includes some minor updates to the desktop and Start Menu strings from Content Design as well.
I also removed the now-useless quicklaunch option (which was only used pre-Windows 7).
Differential Revision: https://phabricator.services.mozilla.com/D148289
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 includes some minor updates to the desktop and Start Menu strings from Content Design as well.
I also removed the now-useless quicklaunch option (which was only used pre-Windows 7).
Differential Revision: https://phabricator.services.mozilla.com/D148289
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 includes some minor updates to the desktop and Start Menu strings from Content Design as well.
I also removed the now-useless quicklaunch option (which was only used pre-Windows 7).
Differential Revision: https://phabricator.services.mozilla.com/D148289
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
In addition, this makes the other file associations have a non-default
description, like "Firefox HTML Document", which agrees (at least for
Release and Beta) with what the installer arranges. (The Windows
default description is otherwise "HTML Document", "PDF Document",
etc.)
Differential Revision: https://phabricator.services.mozilla.com/D142304
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 most notable part of this is the rework of DeleteShortcuts to handle the new shortcuts logs in %PROGRAMDATA%.
Also of note is what we're not handling these new shortcuts in UpdateShortcutAppModelIDs/UpdateShortcutsBranding. As far as I can tell, these are one-off fixes to handle old shortcuts. Because we know that the new shortcut creation code will set from the start -- so there's no need to. This means that there's nothing to do during install or post-update.
Differential Revision: https://phabricator.services.mozilla.com/D139884
There are a number of things that make this definition undesirable:
- It assumes MOZ_OFFICIAL_BRANDING means the product is under a
trademark owned by MoFo, which while currently accurate, complicates
things for making the nightly branding an official branding of
the mozilla-central repo (as per bug 1427472), as "Nightly" is not a
trademark.
- Presumably, downstreams may want something similar, but the string
itself assumes the brand is always under a trademark owned by MoFo,
which is not the case for forks.
- The string actually doesn't appear in the installer that people
download and might look at. It appears in the installer executable
that is temporarily extracted to disk from a compressed archive
contained in the actual installer, which itself doesn't include this
string or other strings from the same .nsi file.
Differential Revision: https://phabricator.services.mozilla.com/D134472
This allows MSIX-installed Firefox to be launched through Win+r and Powershell (and probably other places). This feels deceptively simple - but it appears to work.
Differential Revision: https://phabricator.services.mozilla.com/D135638
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
