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
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
We duplicate these functions in two head.js files right now, and I'm
loathe to add a third, so let's extract a shared test module.
Differential Revision: https://phabricator.services.mozilla.com/D111527
When `--backgroundtask TASK` invocations exit, they try to remove
their temporary profile directory. This mostly works, except there
are some very late writes to the profile directory including
`Telemetry.ShutdownTime.txt` and the `security_state` directory. This
commit accommodates by moving the profile directory removal even
later. It might be possible to instead avoid these very late writes,
but that is hard in general, and is more likely to depend on the exact
code invoked by the background task itself.
Differential Revision: https://phabricator.services.mozilla.com/D110472
FILE_FLAG_DELETE_ON_CLOSE had the wrong semantics, rendering the lock
file unusable after it had been closed once.
Delete the lock file in the uninstaller as a simple alternative (given that
the lock file is not in a temporary location on Windows).
For a test I returned to the older form of
test_backgroundtask_update_sync_manager which initially exposed the issue:
It expects the background task to be able to detect the xpcshell instance
after running resetLock, which failed before this fix.
I also extended the original updateSyncManager test to run the second
copy twice, which also catches the issue.
Differential Revision: https://phabricator.services.mozilla.com/D109565
This will be used from the `backgroundupdate` task to fish the default
profile's Telemetry client ID in order to correlate the task's Glean
ping with regular main pings.
Differential Revision: https://phabricator.services.mozilla.com/D107712
This commit does three main things:
1) It allows to configure the global singleton `nsUpdateSyncManager`
with an `nsIFile` rather than having it use the ambient XPCOM
directory service. This allows to initialize the
`nsUpdateSyncManager` very early: before processing updates and long
before XPCOM is initialized. This in turn allows us to determine if
other instances early enough to skip processing updates when
appropriate.
When this initialization path is followed, i.e., in Firefox but not
`xpcshell`, the `xpcom-startup` notification will be received but no
action taken, since the singleton will already exist.
There is a classic time-of-check, time-of-use race window in this
implementation: an instance may be launched immediately after we check
for other instances. In practice this will result in behaviour that
is alreay possible: two independent instances both processing updates.
It is expected that the updater itself will exclude one of the
instances using its existing mutex.
2) It updates an existing background task test to use an explicit
`nsIFile` rather than the existing directory service method. This
exercises the newer API. There are other tests that might benefit,
but there's no harm in remaining with the previous approach, since
both are required.
3) It adds a new background task test to verify that update processing
is skipped if we're not the sole instance running.
Differential Revision: https://phabricator.services.mozilla.com/D106994
