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 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 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
This is a little tricky since some behaviour must be in the profile
service while some is more naturally in the background tasks mechanism.
Essentially, some background tasks will have a consistent profile
location determined by their "profile prefix", which includes vendor,
installation hash, and background task name. Right now, those tasks are
determined by their task name, but in the future we could make this more
flexible.
A few technical notes:
1. I elected to not assume (or provide) a directory service provider
in the relevant helper, mostly to ease future commits that might
pull this functionality forward in the startup process.
2. These background task profiles are placed in "Background Tasks
Profiles" on relevant platforms (non-Unix and macOS), sibling to
"Profiles".
3. To avoid any possible vulnerability with predictable profile
directories, these non-ephemeral background task profiles are
salted. An entry is placed in the `BackgroundTasksProfiles` section
of `profiles.ini` mapping the profile prefix to the relative salted
path.
Differential Revision: https://phabricator.services.mozilla.com/D149919
This allows the profile service to handle `XRE_PROFILE_PATH`,
`--profile`, etc as normal before choosing a "default" background task
profile directory.
Differential Revision: https://phabricator.services.mozilla.com/D149918
The default browsing profile's targeting snapshot is read using the
standard `BackgroundTasksUtils.jsm` helpers, which allow setting the
profile location for testing.
The targeting snapshot is provided in the triggering context under
`defaultProfile`, allowing both the background task profile's
targeting (for things like current Firefox version and `currentDate`)
and the default browsing profile's targeting (for things like the
snapshot's `currentDate` and add-ons).
Differential Revision: https://phabricator.services.mozilla.com/D151090
We take a simple approach:
1. We add a test to verify that all getters succeed in background
task mode (save for an exclusion list of getters that access
non-local hosts).
2. We make certain getters background task-aware: for example,
because they require the `AddonsManager` or legacy Telemetry.
This will allow background tasks to access their own targeting as well
as a snapshot of the default profile's targeting.
Differential Revision: https://phabricator.services.mozilla.com/D151089
The chrome manifest flag parsing is not particularly flexible. It's
easiest to duplicate the manifest entries rather than further adjust
the parser.
Differential Revision: https://phabricator.services.mozilla.com/D149950
This verifies that stale temporary profile purging does not interfere
with concurrent temporary profile creation and locking.
Depends on D144775
Differential Revision: https://phabricator.services.mozilla.com/D144328
There are a few ways that we could test this. We could use the
profiler and "File IO" markers, a la
https://searchfox.org/mozilla-central/source/browser/base/content/test/performance/browser_startup_content_mainthreadio.js.
This would profile content that is transient, which could be good or
bad -- temporary files for atomic writes would show up for example.
But in fact there are profile contents created after the profiler is
shut down (including `Telemetry.ShutdownTime.txt`), so this approach
isn't sufficient.
Therefore we do the simpler thing: we simply don't remove the
temporary profile directory after the background task exits.
Differential Revision: https://phabricator.services.mozilla.com/D139909
Background task mode is roughly equivalent to `xpcshell`, but inside
the regular browser startup flow. There is no browser window (no
`Window` at all) and there should be no content processes. It's
sufficient to treat it like `xpcshell`, with its own stripped-down
actor and a few tweaks to the integration points.
The structural changes in this commit keep `--backgroundtask` mode
slim in the regular case when the Devtools are *not* requested. This
is reflected in the small changes needed to the
`browser_xpcom_graph_wait.js` test: loading the Devtools
unconditionally causes a huge amount of code to be loaded. In order
to load the Devtools framework conditionally, we check for
Devtools-specific command line flags and delegate to Devtools when
appropriate. In order to check the command line flags, we turn the
`BackgroundTasksManager` into an XPCOM service, which allows it to be
instantiated by XPCOM in order to handle the command line.
One final note: this leaves two XPCOM components, "backgroundtasks"
and "backgroundtasksmanager". Why not combine them? This is
technically possible but not attractive: we really do want a natural
place for native/C++ code ("backgroundtasks") and JavaScript code
("backgroundtasksmanager").
Differential Revision: https://phabricator.services.mozilla.com/D129771
We may get multiple lines or incomplete lines from the pipe, so we
need to split the data and keep the leftover. This makes debugging a
little more pleasant and allows for the consumer to react to stdout as
it is read.
Differential Revision: https://phabricator.services.mozilla.com/D138222
The aim is to avoid background tasks causing unexpected updates, as
happened when we tried to migrate `pingsender` to a Gecko background
task in Bug 1734262. This commit makes it so that we only process
updates for the `backgroundupdate` task (and the test-only
`shouldprocessupdates` task).
Differential Revision: https://phabricator.services.mozilla.com/D133557
I've elected to rename the function from `Should...` to
`ShouldNot...`, but not to rename the various test files. The
functionality under test is both "should" and "should not", so I think
the churn of renaming is not justified.
This rearranges the deck chairs to accommodate testing the new
functionality in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D133556
