Background tasks are potentially very short living, such that things launched asynchronously during process startup might not have finished initializing when we are asked to shutdown.
In order to mitigate this, we introduce a configurable `backgroundTaskMinRuntimeMS` (default 500ms) that guarantees that a background task will last at least that time.
Documentation will be added in bug 1833198.
Differential Revision: https://phabricator.services.mozilla.com/D177879
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
The code coverage harness outputs a line like:
```
[CodeCoverage] Setting handlers for process 10953.
```
in early startup, and it's not worth working around it.
Differential Revision: https://phabricator.services.mozilla.com/D164375
The main reason to do this is to avoid polluting developer's terminals
_after_ Firefox exits; regular users shouldn't see `pingsender`
logging at all.
It's not technically difficult to actually launch with null stdout and
stderr, but it is quite onerous: we have at least two ways to launch
processes (`LaunchApp` and `nsIProcess`), with platform specific
differences and implementation specific options. This approach is at
least brief and easy to understand.
Differential Revision: https://phabricator.services.mozilla.com/D163153
This patch replaces the previous ContractID-based lookup system for protocol
handlers, and replaces it with a new custom system in nsIOService. It will be
pre-populated with non-overridable static protocol handlers using the
StaticComponents infrastructure added in the previous part, and callers can
also dynamically register new protocol handlers at runtime.
This new system is intended to provide access to the default port and
non-dynamic protocol flags off-main-thread, by requiring these values to be
provided up-front as constants, rather than getting them from the xpcom
interface. The data is then guarded by an RWLock.
Callers which look up specific handlers by their contractID are not changed, as
the contract IDs for existing handlers have not been changed, so the lookup
will still succeed.
This change as-implemented breaks the nsGIOProtocolHandler on Linux, as it
removes the special code which would try to use that handler for some
protocols. This will be fixed in a later part by making the
nsGIOProtocolHandler use the dynamic registration APIs to register and
un-register protocol handlers at runtime in response to the GIO pref.
Differential Revision: https://phabricator.services.mozilla.com/D162804
This patch replaces the previous ContractID-based lookup system for protocol
handlers, and replaces it with a new custom system in nsIOService. It will be
pre-populated with non-overridable static protocol handlers using the
StaticComponents infrastructure added in the previous part, and callers can
also dynamically register new protocol handlers at runtime.
This new system is intended to provide access to the default port and
non-dynamic protocol flags off-main-thread, by requiring these values to be
provided up-front as constants, rather than getting them from the xpcom
interface. The data is then guarded by an RWLock.
Callers which look up specific handlers by their contractID are not changed, as
the contract IDs for existing handlers have not been changed, so the lookup
will still succeed.
This change as-implemented breaks the nsGIOProtocolHandler on Linux, as it
removes the special code which would try to use that handler for some
protocols. This will be fixed in a later part by making the
nsGIOProtocolHandler use the dynamic registration APIs to register and
un-register protocol handlers at runtime in response to the GIO pref.
Differential Revision: https://phabricator.services.mozilla.com/D162804
This patch misses one notable nsIUpdateChecker consumer: AppUpdater. This patch stack makes major changes to AppUpdater, so those changes will be made in their own patch later in this patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D159295
This patch misses one notable nsIUpdateChecker consumer: AppUpdater. This patch stack makes major changes to AppUpdater, so those changes will be made in their own patch later in this patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D159295
This patch misses one notable nsIUpdateChecker consumer: AppUpdater. This patch stack makes major changes to AppUpdater, so those changes will be made in their own patch later in this patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D159295
This background task currently is generic enough that it can be reused for other components, namely QuotaCleaner in the child patches. Renaming makes it clear that it's generic.
Differential Revision: https://phabricator.services.mozilla.com/D156912
This fixes ESLint issues raised by mozilla/valid-services-properties.
This also changes follow-on issues to use Services.appinfo rather than getService.
Differential Revision: https://phabricator.services.mozilla.com/D159461
This was oversight. In background tasks, I took some care to provide
the snapshot of the default profile's targeting state to the Firefox
Messaging System, but it also needs to be provided to Nimbus to filter
experiments directly.
For expedience, I provide an extra targeting context object to
`ExperimentManager.onStartup`.
The targeting contexts for Nimbus proper and Firefox Messaging System
are somewhat independent; that's why the triggering context remains in
the invocation of `sendTriggerMessage`.
Depends on D154308
Differential Revision: https://phabricator.services.mozilla.com/D154309
This commit does several things:
1. It configures a new Nimbus feature and corresponding message group
`backgroundTaskMessage`.
2. It configures `Firefox Messaging Experiments` to use the new
Nimbus feature in background tasks. The existing Remote Settings
collection `nimbus-desktop-experiments` continues to be used.
These configurations are achieved by setting preferences in
`backgroundtasks_browser.js`, which is applied on top of
`firefox.js` prefs by the preference service. These preferences
apply to every background task.
3. It implements functions for enabling Nimbus and the Firefox
Messaging System (and Messaging Experiments) that can be used by
arbitrary background tasks.
It is assumed (but not enforced here) that such tasks will use
non-ephemeral (persistent) profiles, so that Remote Settings
incremental sync, Nimbus bucketing, and Messaging System message
limits, function as expected.
4. It adds a new `message` background task specifically for testing
background task messages. Invoke the testing task with command
lines like `firefox --backgroundtask message ...`.
To ease testing, the framework accepts `--url about:studies?...`
arguments from the Experimenter Web UI to explicitly opt-in to
specific experiment branches.
This task is complicated because it is intended both for QA to
manually invoke, but also to be used by automated tests.
Eventually the existing `backgroundupdate` task will use the new
functions, just as the testing `message` task does.
Differential Revision: https://phabricator.services.mozilla.com/D150521
This commit does several things:
1. It configures a new Nimbus feature and corresponding message group
`backgroundTaskMessage`.
2. It configures `Firefox Messaging Experiments` to use the new
Nimbus feature in background tasks. The existing Remote Settings
collection `nimbus-desktop-experiments` continues to be used.
These configurations are achieved by setting preferences in
`backgroundtasks_browser.js`, which is applied on top of
`firefox.js` prefs by the preference service. These preferences
apply to every background task.
3. It implements functions for enabling Nimbus and the Firefox
Messaging System (and Messaging Experiments) that can be used by
arbitrary background tasks.
It is assumed (but not enforced here) that such tasks will use
non-ephemeral (persistent) profiles, so that Remote Settings
incremental sync, Nimbus bucketing, and Messaging System message
limits, function as expected.
4. It adds a new `message` background task specifically for testing
background task messages. Invoke the testing task with command
lines like `firefox --backgroundtask message ...`.
To ease testing, the framework accepts `--url about:studies?...`
arguments from the Experimenter Web UI to explicitly opt-in to
specific experiment branches.
This task is complicated because it is intended both for QA to
manually invoke, but also to be used by automated tests.
Eventually the existing `backgroundupdate` task will use the new
functions, just as the testing `message` task does.
Differential Revision: https://phabricator.services.mozilla.com/D150521
This commit does several things:
1. It configures a new Nimbus feature and corresponding message group
`backgroundTaskMessage`.
2. It configures `Firefox Messaging Experiments` to use the new
Nimbus feature in background tasks. The existing Remote Settings
collection `nimbus-desktop-experiments` continues to be used.
These configurations are achieved by setting preferences in
`backgroundtasks_browser.js`, which is applied on top of
`firefox.js` prefs by the preference service. These preferences
apply to every background task.
3. It implements functions for enabling Nimbus and the Firefox
Messaging System (and Messaging Experiments) that can be used by
arbitrary background tasks.
It is assumed (but not enforced here) that such tasks will use
non-ephemeral (persistent) profiles, so that Remote Settings
incremental sync, Nimbus bucketing, and Messaging System message
limits, function as expected.
4. It adds a new `message` background task specifically for testing
background task messages. Invoke the testing task with command
lines like `firefox --backgroundtask message ...`.
To ease testing, the framework accepts `--url about:studies?...`
arguments from the Experimenter Web UI to explicitly opt-in to
specific experiment branches.
This task is complicated because it is intended both for QA to
manually invoke, but also to be used by automated tests.
Eventually the existing `backgroundupdate` task will use the new
functions, just as the testing `message` task does.
Differential Revision: https://phabricator.services.mozilla.com/D150521
