1748684 - Add support for Experimental APIs in the WebIDL bindings

Status: NEW

(WebExtensions :: General, task, P3)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

Privileged extensions are allowed to include as part of the extension itself a set of experimental APIs, described by the same kind of JSONSchema used to describe the API natively integrated in the build.

Unfortunately the python script that we have created to help to convert the JSONSchema API definitions into WebIDL definitions can't cover this case, because the API is unknown at build time and they can be added and removed at runtime (when the related extension is enabled/disabled), and so we will need a different strategy.

The goal of this issue is to determine a reasonable strategy, and implement it to allow privileged extensions to be migrated to MV3 background service workers in the future (as part of transition them from MV2 manifest to MV3 manifest, especially if the background script did not need any DOM API that wouldn't be available in a worker global).

As a side note, one possible (and simple enough approach) would be to:

• expose a single privileged API namespace that provides a single method to create an API object which represents the Experimental API namespace (and this method could check that the requested API namespace is an experimental API embedded in the caller extension and fail if it is not)
• then the API object returned would be providing generic methods to add/remove listeners and call API async methods etc.