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
This version is as simple as I can make it. It simply expects the JS
debugger to stop on the breakpoint added automatically by the
backgroundtask debugger command line processing (using
`setBreakpointOnLoad`) and disconnects, expecting the task to continue
execution and exit with exit code 0.
In the future, we'd like to interact with the task environment, for example to:
1. stop on the automatic breakpoint
2. continue
3. stop on a `debugger;`
4. set the task's exit code from a failure code to exit code 0
5. continue
6. verifies the tasks's exit code is 0.
Sadly my attempts to do this fail intermittently in automation.
Differential Revision: https://phabricator.services.mozilla.com/D139156
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
This change is needed to avoid toolkit/components/backgroundtasks/tests/browser/browser_xpcom_graph_wait.js test failures where the nsUUIDGenerator service was loaded during ASan test runs but not non-ASan test runs (due to differences in temp profile directory paths). With this change, the nsUUIDGenerator service is no longer needed in BackgroundTasks.
Using nsID::GenerateUUIDInPlace() also avoids the overhead of instantiating the nsUUIDGenerator service.
Depends on D136992
Differential Revision: https://phabricator.services.mozilla.com/D136993
Once we allow lazy initialization for the permission manager, we do not launch it at startup in any kind of process. We thus need to update the allowlist of this test and remove the permission manager and other (networking) modules it started.
Differential Revision: https://phabricator.services.mozilla.com/D133655
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
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.
To avoid the race, we could take the exclusive multi-instance lock
ourselves, but that is strictly more complicated.
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
I've tested this explicitly with `AppUpdateURL` because that's the
policy-controlled value we care about for the first use case for
background tasks, namely the background update agent.
Differential Revision: https://phabricator.services.mozilla.com/D99846
This adds a test to ensure that crash reporting works inside of
`application --backgroundtask ...` invocations. A test-only `crash`
task is added that uses `CrashTestUtils.jsm` to trigger a crash. The
`xpcshell` harness invokes that background task and processes any
minidump and extras just as it does for existing `xpcshell`
subprocesses.
The test is homed in `toolkit/crashreporter`, rather than in
`toolkit/components/backgroundtasks`, because there is special
handling for `CrashTestUtils.jsm` and the `testcrasher` library. It's
probably possible to make that infrastructure usable from multiple
locations but it seems low value.
Differential Revision: https://phabricator.services.mozilla.com/D98096
This establishes a high water mark for code loaded (even after a short
delay) by a background task that does nothing.
Code loaded here means:
1) Chrome JSMs imported using `ChromeUtils.import`;
2) XPCOM services, generally long-lived, loaded using `do_getService`
or `Services.*` or an equivalent;
3) XPCOM components defined in JavaScript and loaded via
`chrome.manifest` entries.
At this time background tasks do not load any of category 3. The
distinction is made because they are reported separately by Gecko.
This test is browser-chrome to make it easy/possible to work with
packaged builds.
Differential Revision: https://phabricator.services.mozilla.com/D98095
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
I've tested this explicitly with `AppUpdateURL` because that's the
policy-controlled value we care about for the first use case for
background tasks, namely the background update agent.
Differential Revision: https://phabricator.services.mozilla.com/D99846
This adds a test to ensure that crash reporting works inside of
`application --backgroundtask ...` invocations. A test-only `crash`
task is added that uses `CrashTestUtils.jsm` to trigger a crash. The
`xpcshell` harness invokes that background task and processes any
minidump and extras just as it does for existing `xpcshell`
subprocesses.
The test is homed in `toolkit/crashreporter`, rather than in
`toolkit/components/backgroundtasks`, because there is special
handling for `CrashTestUtils.jsm` and the `testcrasher` library. It's
probably possible to make that infrastructure usable from multiple
locations but it seems low value.
Differential Revision: https://phabricator.services.mozilla.com/D98096
This establishes a high water mark for code loaded (even after a short
delay) by a background task that does nothing.
Code loaded here means:
1) Chrome JSMs imported using `ChromeUtils.import`;
2) XPCOM services, generally long-lived, loaded using `do_getService`
or `Services.*` or an equivalent;
3) XPCOM components defined in JavaScript and loaded via
`chrome.manifest` entries.
At this time background tasks do not load any of category 3. The
distinction is made because they are reported separately by Gecko.
This test is browser-chrome to make it easy/possible to work with
packaged builds.
Differential Revision: https://phabricator.services.mozilla.com/D98095
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
I've tested this explicitly with `AppUpdateURL` because that's the
policy-controlled value we care about for the first use case for
background tasks, namely the background update agent.
Differential Revision: https://phabricator.services.mozilla.com/D99846
This adds a test to ensure that crash reporting works inside of
`application --backgroundtask ...` invocations. A test-only `crash`
task is added that uses `CrashTestUtils.jsm` to trigger a crash. The
`xpcshell` harness invokes that background task and processes any
minidump and extras just as it does for existing `xpcshell`
subprocesses.
The test is homed in `toolkit/crashreporter`, rather than in
`toolkit/components/backgroundtasks`, because there is special
handling for `CrashTestUtils.jsm` and the `testcrasher` library. It's
probably possible to make that infrastructure usable from multiple
locations but it seems low value.
Differential Revision: https://phabricator.services.mozilla.com/D98096
This establishes a high water mark for code loaded (even after a short
delay) by a background task that does nothing.
Code loaded here means:
1) Chrome JSMs imported using `ChromeUtils.import`;
2) XPCOM services, generally long-lived, loaded using `do_getService`
or `Services.*` or an equivalent;
3) XPCOM components defined in JavaScript and loaded via
`chrome.manifest` entries.
At this time background tasks do not load any of category 3. The
distinction is made because they are reported separately by Gecko.
This test is browser-chrome to make it easy/possible to work with
packaged builds.
Differential Revision: https://phabricator.services.mozilla.com/D98095
There are some complications here to handle unpackaged and packaged
builds. In addition, there could be a difference between App prefs
and GRE prefs. Since the underlying backgroundtasks code is built as
part of Gecko (i.e., `toolkit/...` rather than `browser/...`) I have
favoured GRE prefs. I think, however, that what is written will work
for App-specific prefs, but I'm not concerned with that detail at this
time.
This also add tests for backgroundtask-specific prefs, which are
structured as both xpcshell and mochitest-chrome tests because
locally, the former tests unpackaged builds and the latter can
accommodate testing packaged builds. We could use mochitest-chrome
for both, but this has been pleasant to work with locally.
Differential Revision: https://phabricator.services.mozilla.com/D97510
