This commit uses a "pull" approach, where the experiment details are
fished at presentation-time and the content `tag` updated.
A few notes:
- With this approach, the update function is pushed down to the leaf
node (the toast notification presentation layer). It would be nice to
do this at the experiment layer, but that layer doesn't resolve the
presentation layer at this time, so it would perhaps violate the
abstraction to lift the work higher.
- No effort has been made to mark `tag` as invalid in the messaging
experiment schemas. At this time, there's no provision for fields
accepted at the presentation layer (`ToastNotification.schema.json`)
but not at the experiment layer aggregating
presentations (`BackgroundTaskMessagingExperiment.schema.json`,
`MessagingExperiment.schema.json`). It's likely possible to arrange
this but not worth the effort at this time.
- The actual tag displayed is not captured in the message as it flows
through ASRouter. This is not likely to pose a problem.
- The actual tag displayed might be `optin-...`, potentially
complicating data analysis. Since it's essentially impossible for
regular users to opt-in to _background task_ messages, that's not a
pressing concern.
Differential Revision: https://phabricator.services.mozilla.com/D164508
Add a 1s grace period after waking from sleep in which notifications
from the idle service will be ignored. Break out the idle trigger tests
because we've reached the max statements per function limit.
Differential Revision: https://phabricator.services.mozilla.com/D163303
To debug the idle trigger's interaction with OS sleep state, it's
helpful to know whether sleep/wake notifications were sent. This allows
most of the idle trigger activity to be logged to the console, if the
pref `messaging-system.log` is set to `debug`. The new logging will also
be used to debug the behavior reported in bug 1801301.
Differential Revision: https://phabricator.services.mozilla.com/D163010
To debug the idle trigger's interaction with OS sleep state, it's
helpful to know whether sleep/wake notifications were sent. This allows
most of the idle trigger activity to be logged to the console, if the
pref `messaging-system.log` is set to `debug`. The new logging will also
be used to debug the behavior reported in bug 1801301.
Differential Revision: https://phabricator.services.mozilla.com/D163010
ASRouter's remote message providers were written to include a property
to specify the desired collection on the Remote Settings Kinto server.
But this property was mistakenly labeled `bucket` in many places. This
could be confusing because Kinto storage is organized by both buckets
and collections, with buckets being a higher level of organization and
collections belonging to buckets. Each individual message provider
specifies a collection like "cfr", while the bucket is set by the router
code ("main"). This carried over to everything that interacted with the
providers, so this patch effectively replaces every reference to a
"message provider bucket" with "message provider collection." But more
importantly, provider definitions are stored as JSON strings in
preference values, so these definitions erroneously contained key-value
pairs like `bucket: "cfr"` which should have been `collection: "cfr"`.
That means the pref values themselves must be migrated to ensure that
modified prefs continue to work. Existing tests are updated and a new
test is added for the migrator, to meet minimum coverage requirements.
Documentation is also updated to reflect the correct property name.
Differential Revision: https://phabricator.services.mozilla.com/D162067
Add the highest possible frequency cap to the Firefox View Spotlight message so that it creates ASRouter impressions while still being able to sync across windows/tabs with Firefox View open.
Differential Revision: https://phabricator.services.mozilla.com/D161853
This patch adds a new trigger that will be used to deliver messages to
the user without disrupting their work. The trigger will only fire when
the user starts interacting with the browser (e.g. moving the mouse or
pressing a key) after a given period of time has passed without any user
activity or audio playback. In the initial messages planned for this
trigger, the necessary period of idle time will be 20 minutes. The
trigger fires after a 2 second delay to ensure the user does not miss
the message. Putting the computer to sleep or waking it up from sleep
will reset the idle "timer" to avoid messages being delivered as soon as
the computer is woken up from sleep.
Differential Revision: https://phabricator.services.mozilla.com/D160454
