For now, both these getFront methods are only calling front's constructor and immediately returns the front: https://searchfox.org/mozilla-central/rev/819cd31a93fd50b7167979607371878c4d6f18e8/devtools/shared/protocol.js#1671-1680 const type = types.getType(typeName); if (!type) { throw new Error(`No spec for front type '${typeName}'.`); } if (!type.frontClass) { lazyLoadFront(typeName); } return type.frontClass(client, form); The fronts (and actors) constructors are being defined this way by protocol.js internals: https://searchfox.org/mozilla-central/rev/819cd31a93fd50b7167979607371878c4d6f18e8/devtools/shared/protocol.js#1261-1264 const cls = function() { const instance = Object.create(cls.prototype); instance.initialize.apply(instance, arguments); return instance; }; We would like to introduce a common way to asynchronously initialize front creation in order to extract front specifics out of the toolbox, like these codes: * inspector specifics: https://searchfox.org/mozilla-central/rev/819cd31a93fd50b7167979607371878c4d6f18e8/devtools/client/framework/toolbox.js#2662-2679 * performance specifics: https://searchfox.org/mozilla-central/rev/819cd31a93fd50b7167979607371878c4d6f18e8/devtools/client/framework/toolbox.js#3046-3047 * thread actor specifics: And may be also later, once we would like to convert ThreadClient to a front and inline attachThread into getFront("thread"): https://searchfox.org/mozilla-central/rev/819cd31a93fd50b7167979607371878c4d6f18e8/devtools/client/framework/attach-thread.js#42-108 * console specifics: It would be similar with the console, where we always call attach/startListeners when we instanciate the front/client/actor: https://searchfox.org/mozilla-central/rev/819cd31a93fd50b7167979607371878c4d6f18e8/devtools/client/framework/target.js#490-491 This will be critical for fission as we will start instantiating more than just one instance of these fronts/actors. So that we need a common API to easily create as many as we need and so it has to be uncoupled from the toolbox.

Note that a side effect of this proposal is that it will make TabTarget.getFront become async and may require some significant work to convert all the callsites.

this is the initial commit for moving our fronts to having async instantiation. The next steps will be to migrate all call sites to be async. This may be blocked by some of the getFront work

This is one part of updating the inspectorFront. Unfortunately, the tests need to be dealt with now, specifically those in devtools/server/tests/mochitest. Depends on D8091

this introduces all of the required methods for destruction directly into the front. Depends on D8707

Depends on D8989

Pushed by ystartsev@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a6b4461eadf0 introduce async front instantiation; r=ochameau