Background.service_worker

[Elia Khensamphanh]

Whennew webidl definitions are being introduced for a WebExtensions API, orexisting ones need to be updated to stay in sync with changes applied to theJSONSchema definitions of the same WebExtensions API, the resulting patchwill include a new or changed WebIDL located at dom/webidl and that part of thepatch will require a mandatory review and sign-off from a peer part of thewebidl phabricator review group.

This section includes a brief description about the special setup of thewebidl files related to WebExtensions and other notes useful to theWebIDL peers that will be reviewing and signing off these webidl files.

All the webidl interfaces related to the extensions API are only visible inspecific extension globals: the WebExtensions background service worker(a service worker declared in the extension manifest.json file, throughthe background.service_worker manifest field).

All webidl interfaces related to the WebExtensions API interfaces are exposedthrough the ExtensionBrowser interface, which gets exposed into theServiceWorkerGlobalScope through the ExtensionGlobalsMixin interface andrestricted to the WebExtensions background service worker through themozilla::extensions::ExtensionAPIAllowed helper function.

A previous attempt to create W3C specs for the WebExtensions APIs described in WebIDLsyntaxes ( ) was also using the sameNoInterfaceObject WebIDL attribute on the definitions of the API namespacewith the same motivations (eg. see BrowserExtBrowserRuntime as defined here: -definition-4).

Most of the API methods in generated WebIDL are meant to be implemented using stub methods sharedbetween all WebExtensions API classes, a WebExtensionStub webidl extended attribute specifywhich shared stub method should be used when the related API method is called.

After a new WebIDL definition has been generated, there are a few more steps to ensure thatthe new WebIDL binding is wired up into mozilla-central build system and to be able tocomplete successfully a full Gecko build that include the new bindings.

Once the WebIDL definition for an WebExtensions API namespace has beenimplemented and wired up, the following testing strategies are available tocover them as part of the WebExtensions testing suites:

The xpcshell tests added to this group of xpcshell tests are meant to provide testing coveragerelated to lower level components and behaviors (e.g. when making changes to the shared C++helpers defined in toolkit/components/extensions/webidl-api, or adding new ones).

These tests will often mock part of the internals and use a browser.mockExtensionAPIAPI namespace which is only available in tests and not mapped to any actual API implementation(instead it is being mocked in the test cases to recreate the scenario that the test case is meantto cover).

And so they are not meant to provide any guarantees in terms of consistency of the behaviorof the two different bindings implementations (the new WebIDL bindings vs. the current implementedbindings), instead the other test suites listed in the sections below should be used for that purpose.

All tests in this directory are skipped in builds where the WebExtensions WebIDL API bindingsare being disabled at build time (e.g. beta and release builds, where otherwisethe test would permafail while riding the train once got on those builds).

Unless the background page or scripts are declared as part of the test extension manifest,the test file added to this manifest should be explicitly reviewed to make sure all testsare going to provide the expected test coverage in all modes.

In a background script that runs in both a background page and a backgroundservice worker it may be necessary to run different code for part of thetest, self !== self.window is a simple check that can be used to detect ifthe script is being executed as a background service worker.

On the contrary if the test tasks is covering a scenario that is specific to a background page,and it would need to be permanently skipped while the background script is running as a service worker,it may be more appropriate to split out those tests in a separate test file not included in thismanifest.

I wanted to ask for information. It has been almost 2 years since ui vision has been updated on firefox, there are numerous changes in these 2 years that are not available for those who use firefox extension.

I wonder if you will be able to update after 2 years ui vision for firefox to bring it back up to date as ui vision for Chrome.

My concern is that after 2 years of no updates for ui vision for firefox that it will be out of date and will remain out of date.

=> So our plan is to give Firefox MV3 a few more month to mature and add the still missing features. Then we will start the conversion. Ideally, we have the new Ui.Vision for Firefox version ready sometime during summer. It will have all the features that the Chrome version has.

There are many new commands published in these 2 years for Ui vision Chrome version that currently in ui vision firefox version are not available, read all the news of the ui vision versions for Chrome to see the new commands and changes

There will be no more updates for the old manifest V2 versions of the browser extensions from us. But since our RPA software is open-source, anyone is welcome to backport features from our newer versions to the manifest V2 versions.

As of today, Firefox still does not support background.service_worker. But the Firefox developers are working on it. As soon as the Firefox extension team closes this open bug, we can release a new version of Ui.Vision for Firefox.

3a8082e126