Two parts here:
1) Remove the code that does implicit pinning entirely (this will disable it on Windows 7 as well, which I think is probably the right thing to do at this point).
2) Fix the installer to set a proper default for AddTaskbarSC
Differential Revision: https://phabricator.services.mozilla.com/D164096
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
From quite some time the vast moajority of instances of this dialog are non
resizable, and persisting attributes is now creating problems with the new flex
layout.
Thus, this patch is removing attributes persistence and the dialog duplication
whose only intent was to persist different attributes depending on the dialog
contents.
As a compromise due to not being able to resize the dialog, we increase the
dialog min-width.
Differential Revision: https://phabricator.services.mozilla.com/D160486
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
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
