Per the documentation the system should handle `arguments=dismiss` to fire dismiss event but somehow it still fires activate event. This patch thus handles it manually while still taking advantage of the Windows provided localization of the button.
Differential Revision: https://phabricator.services.mozilla.com/D198286
Per the documentation the system should handle `arguments=dismiss` to fire dismiss event but somehow it still fires activate event. This patch thus handles it manually.
Differential Revision: https://phabricator.services.mozilla.com/D198286
This prevents a failed debug assertion in the image decoder due to color management attempting to initialize off the main thread. This is only an issue for debug builds, release builds instead return an error in color management initialization and otherwise continue on to decode the image correctly.
Differential Revision: https://phabricator.services.mozilla.com/D197028
When `nsIWindowsAlertNotification`'s `handleActions` property is set to true, actions are sent in the notification observer's `aData` field instead of the notification cookie.
Differential Revision: https://phabricator.services.mozilla.com/D196613
This commit replaces two existing launch argument keys, `launchURL`
and `privilegedName`, with an opaque string of data. Here opaque
means, "does not need to be inspected by the Windows notification
server DLL" (and in general, by the system backend components).
The existing `action` argument key was always intended for this
purpose but was not used in the first implementation. Here, we make
`action` a stringified JSON object, which is easy for API consumers to
manage and generalizes to (mostly) arbitrary relaunch data.
This JSON object is a compound `notificationData` object containing
both:
- the consumer-provided `opaqueRelaunchData` (generally, an action);
- and implementation-provided details (the alert's name, if
privileged, etc).
This compound object and the fact that everything transits as strings
makes everything a little more confusing than it really is.
The API to this opaque relaunch data is based on strings for
convenience. It would be possible to manage JSON objects, perhaps by
using `nsIStructuredCloneContainer` to serialize "structured clone
encodable" JS objects across the process boundaries, but managing the
objects and container in that approach is much more effort than having
the API consumer stringify as desired.
In addition, this patch makes the notification server extract the
Firefox `action` data from the Windows toast `arguments` passed to the
server callback. Since this fallback data is now provided to Firefox
at launch, there's no need to fetch it from the Windows notification
object; we simply need to know whether to pass through to a Windows
8.1 callback (`tagWasHandled=true`) or to act on the fallback data
(`tagWasHandled=false`). This is simpler than teaching Firefox to
extract the arguments for toast itself or the appropriate action
button.
Differential Revision: https://phabricator.services.mozilla.com/D182314
Use PNGs instead of BMPs for Windows toast notification images.
BMPs were isolated as the cause of Windows toasts failing to display images when provided in the `src` attribute of the `<image>` tag for Windows 8. The same was not observed for PNGs.
This issue only affects Windows 8.
Differential Revision: https://phabricator.services.mozilla.com/D173787
`IToastNotification2` is not available in Windows 8, so querying it caused the toast to fail. When the content was only text, the toast would immediately fail triggering a fallback to XUL style alerts. When it contained an image, the async image load caused the toast to fail after the fallback branch had been decided.
The toast tag assigned and retrieved from `IToastNotification2` is used by Windows to track notifications in the Action Center and is only relevant in the context of Windows 10+.
Differential Revision: https://phabricator.services.mozilla.com/D173496
Prior to this commit the `ToastNotification`'s observer registration doesn't work due to `ToastNotification` not implementing `nsIWeakReference` while attempting to register itself as an observer as a weak reference.
Differential Revision: https://phabricator.services.mozilla.com/D155764
The immediate effect is to make any image larger and more prominent.
This might not be the right option for regular DOM notifications,
which support only `icon` (and not `image`) in Firefox at this time,
but we can adjust (perhaps limiting the generic template to privileged
alerts) as we need in the future.
Differential Revision: https://phabricator.services.mozilla.com/D156873
On Windows, when an alert is privileged and `name` is non-empty, round
trip its `name` (as `privilegedName`) through the Windows notification
mechanism, and provide it to the "relaunch" callback.
Differential Revision: https://phabricator.services.mozilla.com/D156636
When the notification server callback is executed by the Windows
notification system, it invokes Firefox with additional command line
parameters, most importantly the Windows-specific notification
"Windows tag".
If no appropriate Firefox is running, the command line will be
processed, the provided Windows tag will be inspected (and seen to not
be registered with this running Firefox instance) and a "launch URL"
stored as part of the Windows notification itself opened (if one is
provided).
If an appropriate Firefox is running, the remoting protocol will
forward this command line to the running instance. If the instance
recognizes the provided `--notification-windowsTag`, the command line
will be ignored. When the notification server exits, Windows will
fallback to the Windows 8.1 style notification callbacks registered
for this Windows tag and the existing (non notification server)
behaviour will occur.
In fact, the server therefore waits for a Windows tag-specific system
event to be signalled by the invoked Firefox (or a sibling process).
If we were to return `S_OK` from the notification server immediately,
and a running Firefox process would handle the notification via
Windows 8.1-style notification callbacks, then Windows would fall back
to those callbacks. The invoked callbacks unregister themselves upon
completion, often before the launched Firefox has an opportunity to
process the command line. By waiting for this system event, we allow
the invoked Firefox to process the command line while its own
notification callbacks are registered and therefore recognize that its
callbacks will handle the notification.
Differential Revision: https://phabricator.services.mozilla.com/D154468
In background task mode:
1. Re-launch Firefox into the default browsing profile, not the
(possibly ephemeral) background task profile.
2. Don't show the in-product notification settings, which won't apply
to the relevant Firefox profile.
Differential Revision: https://phabricator.services.mozilla.com/D155908
Use the existing mName field of alert which includes the host port and tag (or uuid) for Windows notification tag.
When a notification originates from the browser chrome, generate an identify on the fly as before.
The tag is hashed in order to fit the 16 character limit for tags. Note the limit was bumped to 64 in Windows 10 Creators Update.
Differential Revision: https://phabricator.services.mozilla.com/D155140
When the notification server callback is executed by the Windows
notification system, it invokes Firefox with additional command line
parameters, most importantly the Windows-specific notification
"Windows tag".
If no appropriate Firefox is running, the command line will be
processed, the provided Windows tag will be inspected (and seen to not
be registered with this running Firefox instance) and a "launch URL"
stored as part of the Windows notification itself opened (if one is
provided).
If an appropriate Firefox is running, the remoting protocol will
forward this command line to the running instance. If the instance
recognizes the provided `--notification-windowsTag`, the command line
will be ignored. When the notification server exits, Windows will
fallback to the Windows 8.1 style notification callbacks registered
for this Windows tag and the existing (non notification server)
behaviour will occur.
In fact, the server therefore waits for a Windows tag-specific system
event to be signalled by the invoked Firefox (or a sibling process).
If we were to return `S_OK` from the notification server immediately,
and a running Firefox process would handle the notification via
Windows 8.1-style notification callbacks, then Windows would fall back
to those callbacks. The invoked callbacks unregister themselves upon
completion, often before the launched Firefox has an opportunity to
process the command line. By waiting for this system event, we allow
the invoked Firefox to process the command line while its own
notification callbacks are registered and therefore recognize that its
callbacks will handle the notification.
Differential Revision: https://phabricator.services.mozilla.com/D154468
In background task mode:
1. Re-launch Firefox into the default browsing profile, not the
(possibly ephemeral) background task profile.
2. Don't show the in-product notification settings, which won't apply
to the relevant Firefox profile.
Differential Revision: https://phabricator.services.mozilla.com/D155908
Use the existing mName field of alert which includes the host port and tag (or uuid) for Windows notification tag.
When a notification originates from the browser chrome, generate an identify on the fly as before.
The tag is hashed in order to fit the 16 character limit for tags. Note the limit was bumped to 64 in Windows 10 Creators Update.
Differential Revision: https://phabricator.services.mozilla.com/D155140
This allows Windows native notification action buttons to access the
built-in "dismiss" and "snooze" support without requiring a Firefox
invocation.
Differential Revision: https://phabricator.services.mozilla.com/D155906
Also moved from `typedef` to `using _ =` syntax to match new templated import of `ComPtr` in ToastNotificationHandler.h.
Depends on D155525
Differential Revision: https://phabricator.services.mozilla.com/D155526
Windows toast actions (buttons) override the launch argument. The launch arguments are necessary for the notification server to reconstruct the source of the toast, therefore we prepend it to the action argument.
Differential Revision: https://phabricator.services.mozilla.com/D152466
Adds a GUID to the notification's launch attribute too verify a timeout dismissed event doesn't remain in the Action Center.
Remove event hiding to allow notifications to be acted upon after the page or browser is closed.
Differential Revision: https://phabricator.services.mozilla.com/D151741
Adds `program` and `profile` paths to Windows toast notifications so that the COM server can reconstruct the origin in order to relaunch the application.
Differential Revision: https://phabricator.services.mozilla.com/D151740
For MSIX packages, the package AUMID is used.
For NSIS/MSI installs, AUMID is retrieve from HKCR.
For portable builds, the registry is updated at runtime to populate icons, display name, and the COM server.
The COM server has been registered as will be implemented using DllSurrogate; this allows us to offload managing the eventloop and lifetime of the COM server to dllhost.exe, and minimizes the added code complexity.
The COM server is loaded as a separate executable from the sending process to prevent issues that would occur when multiple instances of the sending process (e.g. profiles running in parallel) try to stand up parallel COM servers. The separated COM executable also allows for multiple applications to share a common COM server.
Bonus: fixes Bug 1500054, Bug 1766095, and Bug 1743424.
Differential Revision: https://phabricator.services.mozilla.com/D151739
Windows toast actions (buttons) override the launch argument. The launch arguments are necessary for the notification server to reconstruct the source of the toast, therefore we prepend it to the action argument.
Differential Revision: https://phabricator.services.mozilla.com/D152466
Kagami Sascha Rosylight