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
This allows us to fix a bug where when our current Private Browsing shortcuts are pinned to the Start Menu, they use the regular Firefox Visual Elements (which is the non-Private Browsing logo). I tried to make this as minimal and braindead as possible.
Differential Revision: https://phabricator.services.mozilla.com/D151538
This implements a COM Server and returns objects implementing INotificationActivationCallback. This allows Firefox notifications to be acted upon even after the main process exits.
COM objects require a (normally static) CLSID in the registry to be identified by other apps. To prevent CLSID duplication between parallel installs and portable/development builds, this implementation inspects the registry when a COM object CLSID is requested, and returns an object if the CLSID's InprocServer32 key matches the path of the DLL.
Differential Revision: https://phabricator.services.mozilla.com/D149182
This implements a COM Server and returns objects implementing INotificationActivationCallback. This allows Firefox notifications to be acted upon even after the main process exits.
COM objects require a (normally static) CLSID in the registry to be identified by other apps. To prevent CLSID duplication between parallel installs and portable/development builds, this implementation inspects the registry when a COM object CLSID is requested, and returns an object if the CLSID's InprocServer32 key matches the path of the DLL.
Differential Revision: https://phabricator.services.mozilla.com/D149182
This commit does several things:
1. It configures a new Nimbus feature and corresponding message group
`backgroundTaskMessage`.
2. It configures `Firefox Messaging Experiments` to use the new
Nimbus feature in background tasks. The existing Remote Settings
collection `nimbus-desktop-experiments` continues to be used.
These configurations are achieved by setting preferences in
`backgroundtasks_browser.js`, which is applied on top of
`firefox.js` prefs by the preference service. These preferences
apply to every background task.
3. It implements functions for enabling Nimbus and the Firefox
Messaging System (and Messaging Experiments) that can be used by
arbitrary background tasks.
It is assumed (but not enforced here) that such tasks will use
non-ephemeral (persistent) profiles, so that Remote Settings
incremental sync, Nimbus bucketing, and Messaging System message
limits, function as expected.
4. It adds a new `message` background task specifically for testing
background task messages. Invoke the testing task with command
lines like `firefox --backgroundtask message ...`.
To ease testing, the framework accepts `--url about:studies?...`
arguments from the Experimenter Web UI to explicitly opt-in to
specific experiment branches.
This task is complicated because it is intended both for QA to
manually invoke, but also to be used by automated tests.
Eventually the existing `backgroundupdate` task will use the new
functions, just as the testing `message` task does.
Differential Revision: https://phabricator.services.mozilla.com/D150521
This commit does several things:
1. It configures a new Nimbus feature and corresponding message group
`backgroundTaskMessage`.
2. It configures `Firefox Messaging Experiments` to use the new
Nimbus feature in background tasks. The existing Remote Settings
collection `nimbus-desktop-experiments` continues to be used.
These configurations are achieved by setting preferences in
`backgroundtasks_browser.js`, which is applied on top of
`firefox.js` prefs by the preference service. These preferences
apply to every background task.
3. It implements functions for enabling Nimbus and the Firefox
Messaging System (and Messaging Experiments) that can be used by
arbitrary background tasks.
It is assumed (but not enforced here) that such tasks will use
non-ephemeral (persistent) profiles, so that Remote Settings
incremental sync, Nimbus bucketing, and Messaging System message
limits, function as expected.
4. It adds a new `message` background task specifically for testing
background task messages. Invoke the testing task with command
lines like `firefox --backgroundtask message ...`.
To ease testing, the framework accepts `--url about:studies?...`
arguments from the Experimenter Web UI to explicitly opt-in to
specific experiment branches.
This task is complicated because it is intended both for QA to
manually invoke, but also to be used by automated tests.
Eventually the existing `backgroundupdate` task will use the new
functions, just as the testing `message` task does.
Differential Revision: https://phabricator.services.mozilla.com/D150521
This commit does several things:
1. It configures a new Nimbus feature and corresponding message group
`backgroundTaskMessage`.
2. It configures `Firefox Messaging Experiments` to use the new
Nimbus feature in background tasks. The existing Remote Settings
collection `nimbus-desktop-experiments` continues to be used.
These configurations are achieved by setting preferences in
`backgroundtasks_browser.js`, which is applied on top of
`firefox.js` prefs by the preference service. These preferences
apply to every background task.
3. It implements functions for enabling Nimbus and the Firefox
Messaging System (and Messaging Experiments) that can be used by
arbitrary background tasks.
It is assumed (but not enforced here) that such tasks will use
non-ephemeral (persistent) profiles, so that Remote Settings
incremental sync, Nimbus bucketing, and Messaging System message
limits, function as expected.
4. It adds a new `message` background task specifically for testing
background task messages. Invoke the testing task with command
lines like `firefox --backgroundtask message ...`.
To ease testing, the framework accepts `--url about:studies?...`
arguments from the Experimenter Web UI to explicitly opt-in to
specific experiment branches.
This task is complicated because it is intended both for QA to
manually invoke, but also to be used by automated tests.
Eventually the existing `backgroundupdate` task will use the new
functions, just as the testing `message` task does.
Differential Revision: https://phabricator.services.mozilla.com/D150521
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's no current use for setting `JS_BINARY` in `packager.mk`, so
remove it while we're here. I elected to make it easy to add new file
types to minify rather than to make it easy to specify `JS_BINARY`,
since the latter mechanism is strictly more general and could be used
in future for things other than minification.
Differential Revision: https://phabricator.services.mozilla.com/D138364
Ben Hearsum
Nicholas Rishel
Iulian Moraru
Cristian Tuns
John Bieling
Nick Alexander
Butkovits Atila
smolnar
Kris Maglione
Marian-Vasile Laza
Sylvestre Ledru