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
If Firefox is the default app and pinned to the dock/taskbar, the
primary CTA on the welcome screen will have the same effect as the
secondary CTA. So we can hide one of them. The non-MR page already has
this feature and elects to hide the secondary CTA, so do the same here.
Differential Revision: https://phabricator.services.mozilla.com/D157019
In HCM on Windows, background colors are overridden by the HCM theme's
default background value. And if a CSS background property has more
than 1 layer, only the last layer can include a background-color, so I
suspect that if it has one, background-images on the previous layers
will be obscured by the overridden default background on the last
layer. This patch circumvents this by putting the background-color on
the same layer as the background-image.
Differential Revision: https://phabricator.services.mozilla.com/D156719
I don't see any reason to keep this under the same namespace as the other former `privacySegmentation` prefs - but perhaps I'm missing something here.
Depends on D156733
Differential Revision: https://phabricator.services.mozilla.com/D156734
Also include pocket logged in status, which (because it's not a pref) is
sampled over time.
Also also, include the search field pref.
Differential Revision: https://phabricator.services.mozilla.com/D155755
Remove the privacy segmentation screen unless a Nimbus variable or its fallback
pref is set. Bug 1788967 sets this pref to false, so this should remove the
screen by default but leave it available for us to continue work on it.
Differential Revision: https://phabricator.services.mozilla.com/D156330
Everything here is Windows-only for now, since that's the immediate
use case and these implementation details are specific to Windows
native notifications relaunching Firefox when it is not running --
functionality not supported by the other system alert backends at this
time.
This commit adds a `launch_url` parameter to `ToastNotification`.
This should be viewed as the simplest possible "action" that a toast
notification can take when it is clicked, namely navigating to the
given URL. In the future, we might generalize this to describe more
of the existing actions (like opening settings, snoozing or dismissing
the toast, etc), but for now, this handles my use case.
In addition, this uses `content.tag` as the alert `name`, allowing to
replace existing toast notifications.
Differential Revision: https://phabricator.services.mozilla.com/D155912
`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
For consistency, always return a boolean for `userEnabledActiveColorway` targeting param.
This change should have no effect on current functionality.
Differential Revision: https://phabricator.services.mozilla.com/D155847
