Workflow for creating a new WebIDL bindings for an extension API

As part of Bug 1688040 we are introducing a python script to simplify the workflow to bootstrap a new WebIDL bindings from an API namespace JSONSchema, but to fully wiring up the new WebIDL bindings there are some more steps, e.g.:

• adding a new entry to dom/bindings/Bindings.conf
• changes to moz.build files to include the new webidl and cpp files to the build
• adding the new API to ExtensionBrowser.webidl and ExtensionBrowser.h/ExtensionBrowser.cpp

The python script part of Bug 1688040 may help by doing some more sanity checks automatically (e.g. just checking if the necessary content seems to be already there, parsing the file if possible without increasing the script complexity too much) and suggest what seems to still be missing, but fully automate these final steps in a non-fragile way may be tricky if we want to keep that python script as simple as possible (e.g. those files contain comment which would need to be preserved, also the moz.build files wants the entries to be alphabetically ordered).

Some in-tree docs would be useful to describe these steps in enough detail (and update them when necessary), the script would instead do the sanity checks and provide links to the relevant in-tree doc pages.

High level view of the WebIDL API request handling

Besides documenting the workflow for adding or changing the WebIDL bindings for a WebExtensions API, the in-tree docs should also provide an high level view of the architecture, in particular how the WebExtensions APIs called from the extension code running on the service worker thread are received and handled by the WebExtensions framework internals.

https://hg.mozilla.org/mozilla-central/rev/fdcd6e2672ee

https://hg.mozilla.org/mozilla-central/rev/bd0516734709

The leave-open keyword is there and there is no activity for 6 months.
:rpl, maybe it's time to close this bug?
For more information, please visit auto_nag documentation.