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
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
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
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
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
That is, treat it as a hint if called before open, and as an override if
called after. Override the hint on open.
This is a less invasive change that is green on try and also fixes the
issue.
Differential Revision: https://phabricator.services.mozilla.com/D145098
