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
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
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
`launchURL` captures the URL that triggered the alert, if it comes
from a DOM notification. If Firefox is launched when not already
running to handle an alert, it will navigate to this URL.
This URL can be set, and chrome privileged alerts can use this to
launch Firefox to a specific URL when it is launched. Toast
notifications popped by background tasks will use this to re-engage
Firefox users to a campaign-specific URL.
This functionality will be tested in the Windows-specific tests
accompanying Bug 1781929.
Differential Revision: https://phabricator.services.mozilla.com/D155907
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
The alert.properties file is not migrated here, as its contents are
also used by OS-specific alert notifications:
- widget/cocoa/OSXNotificationCenter.mm
- widget/windows/ToastNotificationHandler.cpp
Differential Revision: https://phabricator.services.mozilla.com/D154380
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
The 'location: true' addition has filtered down to ESLint a while ago, so we no longer need to define it ourselves.
sizeToContent can be used from the window object directly.
Differential Revision: https://phabricator.services.mozilla.com/D145720
Automatically generated rewrites of all ParamTraits and IPDLParamTraits
implementations in-tree to use IPC::Message{Reader,Writer}.
Differential Revision: https://phabricator.services.mozilla.com/D140004
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
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
DelayedDeleteRunnable would schedule itself twice and use input priority
for the second time because it only wants to run after everything
that could possibly touch this tab. This was needed because we were
strict with IPC messages. However, this is no longer needed because
IPC messages with destroyed actors will be discarded nowadays, so
we don't have to use input priority anymore.
Another reason for making this change is that input events could be
suspended when the runnable is about to run, so we need to either
use a different priority or resume input events.
Differential Revision: https://phabricator.services.mozilla.com/D100345
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
