Bugzilla

I’ve extracted the relevant files and bundled them into an add-on that registers them for access via chrome URIs. However, this approach only works with unbranded builds of Firefox, but not with Beta or Release versions.

Registering a chrome handler requires meeting certain [prerequisites](https://searchfox.org/mozilla-central/rev/f571db8014431de31d245017e2f5457046aec4ea/toolkit/mozapps/extensions/internal/AddonSettings.sys.mjs#103-114):

* `extensions.experiments.enabled` must be set to `true` to use the registration API.
* In Beta/Release builds, the `Cu.isInAutomation` flag also needs to be `true`, which is a flag that is never true when running tests via Marionette.

Since we can’t satisfy the second condition, we’ll need to create a privileged add-on similar to [quitter](https://github.com/mozilla-extensions/quitter). This kind of add-on can be signed and checked into the tree as an XPI, just like [tools/quitter/](https://searchfox.org/mozilla-central/source/tools/quitter/).

Proposed Workflow for Updating the Extension:

1. When test files need updating, use the upstream repository. You can generate an unsigned XPI locally using the `webext` tool to test the changes right away.
2. Request signing for the updated add-on. This process is mostly automated, though some steps may require manual intervention.
3. Once signed, stash the updated XPI in `mozilla-central` under `/remote/test/extensions/chrome-assets/`.
4. Submit a new Phabricator review to land the changes.

With the add-on-based approach in place, we’ll also need to implement the following:

* Add a helper method to the Marionette test framework (either the test case or harness) that installs the add-on into the active profile when tests require access to `chrome://` URIs. This add-on should be automatically removed during test teardown. Note that the installation path may differ depending on whether the test is run via `mach` or `mozharness`—see [this logic for reference](https://searchfox.org/mozilla-central/rev/f571db8014431de31d245017e2f5457046aec4ea/testing/mochitest/mochitest_options.py#1151-1161).

* Update all relevant tests to call this helper method when they rely on the `chrome://` resources exposed by the add-on.

* Update `test_archive.py` to include the add-on in the common test package. The final location within the archive should be chosen to allow sharing between Marionette and WDSpec tests.

I’ve extracted the relevant files and bundled them into an add-on that registers them for access via chrome URIs. However, this approach only works with unbranded builds of Firefox, but not with Beta or Release versions.

Registering a chrome handler requires meeting certain [prerequisites](https://searchfox.org/mozilla-central/rev/f571db8014431de31d245017e2f5457046aec4ea/toolkit/mozapps/extensions/internal/AddonSettings.sys.mjs#103-114):

* `extensions.experiments.enabled` must be set to `true` to use the registration API.
* In Beta/Release builds, the `Cu.isInAutomation` flag also needs to be `true`, which is a flag that is never true when running tests via Marionette.

Since we can’t satisfy the second condition, we’ll need to create a privileged add-on similar to [quitter](https://github.com/mozilla-extensions/quitter). This kind of add-on can be signed and checked into the tree as an XPI, just like [tools/quitter/](https://searchfox.org/mozilla-central/source/tools/quitter/).

Proposed Workflow for Updating the Extension:

1. When test files need updating, use the upstream repository. You can generate an unsigned XPI locally using the `webext` tool to test the changes right away.
2. Request signing for the updated add-on. This process is mostly automated, though some steps may require manual intervention.
3. Once signed, stash the updated XPI in `mozilla-central` under `/remote/test/extensions/chrome-assets/`.
4. Submit a new Phabricator review to land the changes.

With the add-on-based approach in place, we’ll also need to implement the following:

* Add a helper method to the Marionette test framework (either the test case or harness) that installs the add-on into the active profile when tests require access to `chrome://` URIs. This add-on should be automatically removed during test teardown. Note that the installation path may differ depending on whether the test is run via `mach` or `mozharness`; see [this logic in mochitests for reference](https://searchfox.org/mozilla-central/rev/f571db8014431de31d245017e2f5457046aec4ea/testing/mochitest/mochitest_options.py#1151-1161).

* Update all relevant tests to call this helper method when they rely on the `chrome://` resources exposed by the add-on.

* Update `test_archive.py` to include the add-on in the common test package. The final location within the archive should be chosen to allow sharing between Marionette and WDSpec tests.