Making ENSURE_SUCCESS return the result of StealNSResult() ensures that
exceptions in the ErrorResult are deal with. We can then signal that through
WouldReportJSException.
Differential Revision: https://phabricator.services.mozilla.com/D214792
Making ENSURE_SUCCESS return the result of StealNSResult() ensures that
exceptions in the ErrorResult are deal with. We can then signal that through
WouldReportJSException.
Differential Revision: https://phabricator.services.mozilla.com/D214792
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
`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
When a notification's originating tab is closed, it remains in the action center and launches to the originating domain when clicked. When the notification is from a private browsing session, the originating domain leaks to a non-private context when a private browsing session is still active. This fixes the leak by closing the notification with it's originating tab.
Differential Revision: https://phabricator.services.mozilla.com/D164296
This adds context to `CloseAlert()` such that explicitly closing the notification e.g. `notification.close()` can be differentiated from a tab or window implicitly closing the notification. This is necessary as we want notifications to persist after a tab or window is closed for Windows.
This change in behavior is necessary to match user expectations. Users expect notifications to persist in the system tray and do not expect notifications to be lost due to a tab being closed. The content of the message is more important than the interaction in that lens. This change is also necessary for parity with Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D161024
Notifications are now routed through a notification DLL server, which receives permission to set the foreground window when invoked. When the server launches Firefox, the command line is redirected to the currently running application. An instance of Firefox running as a remote client doesn't meet Window's criteria for receiving the set foreground permission, breaking the chain of set foreground window permissions.
This change fixes the chain by piping the PID of the notification handling process such that the DLL server can grant it foreground permission directly.
Differential Revision: https://phabricator.services.mozilla.com/D160457
We need to ensure we're not in a `WndProc` callback context when interacting with native notification COM objects, which is currently a problem when called from the command line handler (see Bug 1805802). We achieve this by moving COM work onto a background task which defers processing until after `WndProc` returns.
Now that retrieving the fallback URL occurs on a background task waiting for it before returning would block the main thread. Making `handleWindowsTag` async introduced race conditions with commandline handling, requiring a `enterLastWindowClosingSurvivalArea`/`exitLastWindowClosingSurvivalArea` to prevent misbehavior in case early blank window is pref'd off. In order to simplify exit cleanup, the API was updated to return a `Promise`.
Differential Revision: https://phabricator.services.mozilla.com/D160458
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
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
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
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
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
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
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
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
1. `requireInteraction` already existed, but it doesn't do anything.
This patch makes it mean `scenario="reminder"` in the Windows
Toast notification schema: see
https://docs.microsoft.com/en-us/uwp/schemas/tiles/toastschema/element-toast.
2. `actions` is intended to eventually support the Chrome-only
extension to the Web Notifications API: see
https://developer.mozilla.org/en-US/docs/Web/API/Notification/actions.
3. We run into an `xpconnect` limit on the number of supported
parameters. Rather than bump the limit, which has global
consequence, I added a second `init*` method. The existing
abstraction is horrible, but I can't rework it within my
timelines. Should we choose to invest, we might migrate to WebIDL
so that we can sensibly use options objects.
Differential Revision: https://phabricator.services.mozilla.com/D150667
This also provides an entry point for Windows-specific styling of
alerts, should specific consumers want one: e.g.,
`nsIWindowsAlertsService.showWindowsAlert(...)` allowing to configure
the toast template, for example.
Differential Revision: https://phabricator.services.mozilla.com/D151187
1. `requireInteraction` already existed, but it doesn't do anything.
This patch makes it mean `scenario="reminder"` in the Windows
Toast notification schema: see
https://docs.microsoft.com/en-us/uwp/schemas/tiles/toastschema/element-toast.
2. `actions` is intended to eventually support the Chrome-only
extension to the Web Notifications API: see
https://developer.mozilla.org/en-US/docs/Web/API/Notification/actions.
3. We run into an `xpconnect` limit on the number of supported
parameters. Rather than bump the limit, which has global
consequence, I added a second `init*` method. The existing
abstraction is horrible, but I can't rework it within my
timelines. Should we choose to invest, we might migrate to WebIDL
so that we can sensibly use options objects.
Differential Revision: https://phabricator.services.mozilla.com/D150667
This also provides an entry point for Windows-specific styling of
alerts, should specific consumers want one: e.g.,
`nsIWindowsAlertsService.showWindowsAlert(...)` allowing to configure
the toast template, for example.
Differential Revision: https://phabricator.services.mozilla.com/D151187
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
Peter Van der Beken