Bugzilla

There is actually another way to even simply it more. We discussed that yesterday in the Add-ons meeting and it indeed removes a lot of overhead and I think that this approach would work for us. 

Instead of explicitly providing an add-on for those chrome files we could directly call the chrome registration handler when executing code in the chrome context. An example Marionette tests demonstrates it:

```
    def test_chrome_window(self):
        with self.marionette.using_context("chrome"):
            self.marionette.execute_script("""
                const { FileUtils } = ChromeUtils.importESModule(
                    "resource://gre/modules/FileUtils.sys.mjs"
                );
                XPCOMUtils.defineLazyServiceGetter(
                    this,
                    "aomStartup",
                    "@mozilla.org/addons/addon-manager-startup;1",
                    "amIAddonManagerStartup"
                );
                const registry = Cc["@mozilla.org/chrome/chrome-registry;1"].getService(
                    Ci.nsIChromeRegistry
                );

                const path = "/Users/henrik/code/gecko/remote/test/chrome-assets/";
                const rootURI = Services.io.newFileURI(new FileUtils.File(path));
                const manifestURI = Services.io.newURI(
                    "manifest.json",
                    null,
                    rootURI
                );
                this.chromeHandle = aomStartup.registerChrome(
                    manifestURI,
                    [["content", "remote-chrome", "content/"]]
                );
            """)
            new_window = self.open_chrome_window(
                "chrome://remote-chrome/content/test.xhtml"
            )
```

This works perfectly well in beta and release builds because there is no longer the need for the Experiments API and also the restriction for `Cu.isInAutomation` is cleared. 

I'll check if we can reduce the number of XHTML files so we maybe only need 3 of them for our tests. Given that we will have to share them with upcoming wdspec tests, it's not clear yet where we want to package them. As well we need a solution for the `reftest.xhtml` and `reftest-content.js` files which are needed by wpt upstream as well.

There is actually another way to even simply it more. We discussed that yesterday in the Add-ons meeting and it indeed removes a lot of overhead and I think that this approach would work for us. 

Instead of explicitly providing an add-on for those chrome files we could directly call the chrome registration handler when executing code in the chrome context. An example Marionette tests demonstrates it:

```
    def test_chrome_window(self):
        with self.marionette.using_context("chrome"):
            self.marionette.execute_script("""
                const { FileUtils } = ChromeUtils.importESModule(
                    "resource://gre/modules/FileUtils.sys.mjs"
                );
                XPCOMUtils.defineLazyServiceGetter(
                    this,
                    "aomStartup",
                    "@mozilla.org/addons/addon-manager-startup;1",
                    "amIAddonManagerStartup"
                );
                const registry = Cc["@mozilla.org/chrome/chrome-registry;1"].getService(
                    Ci.nsIChromeRegistry
                );

                const path = "/Users/henrik/code/gecko/remote/test/chrome-assets/";
                const rootURI = Services.io.newFileURI(new FileUtils.File(path));
                const manifestURI = Services.io.newURI(
                    "manifest.json",
                    null,
                    rootURI
                );
                this.chromeHandle = aomStartup.registerChrome(
                    manifestURI,
                    [["content", "remote-chrome", "content/"]]
                );
            """)
            new_window = self.open_chrome_window(
                "chrome://remote-chrome/content/test.xhtml"
            )
```

This works perfectly well in beta and release builds because there is no longer the need for the Experiments API and also the restriction for `Cu.isInAutomation` is cleared. 

I'll check if we can reduce the number of XHTML files so we maybe only need 3 of them for our tests. Given that we will have to share them with upcoming wdspec tests, it's not clear yet where we want to package them. As well we need a solution for the `reftest.xhtml` and `reftest-content.js` files which are needed by reftests under `/layout` as well.