Alexandre Poirot [:ochameau] Reporter
	Description • 6 years ago

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.

	Alexandre Poirot [:ochameau] Reporter
	Comment 1 • 6 years ago

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.

	Yulia Startsev [:yulia] | Back in Oct. Assignee
	Comment 2 • 6 years ago

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

	Yulia Startsev [:yulia] | Back in Oct. Assignee
	Comment 4 • 6 years ago

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

	Yulia Startsev [:yulia] | Back in Oct. Assignee
	Comment 6 • 6 years ago

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

Depends on D8707

	Yulia Startsev [:yulia] | Back in Oct. Assignee
	Comment 7 • 6 years ago

Depends on D8989

	Pulsebot
	Comment 8 • 6 years ago

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

	Cosmin Sabou [:CosminS]
	Comment 9 • 6 years ago
bugherder

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