Closed Bug 1495387 Opened 1 year ago Closed 1 year ago

Allow target.getFront and mainRoot.getFront to execute async initialization function on fronts.


(DevTools :: Framework, enhancement, P2)



(firefox64 fixed)

Firefox 64
Tracking Status
firefox64 --- fixed


(Reporter: ochameau, Assigned: yulia)


(Blocks 2 open bugs)


(Whiteboard: dt-fission)


(1 file, 5 obsolete files)

For now, both these getFront methods are only calling front's constructor and immediately returns the front:
  const type = types.getType(typeName);
  if (!type) {
    throw new Error(`No spec for front type '${typeName}'.`);
  if (!type.frontClass) {
  return type.frontClass(client, form);

The fronts (and actors) constructors are being defined this way by protocol.js internals:
  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:
* performance specifics:
* thread actor specifics:
  And may be also later, once we would like to convert ThreadClient to a front and inline attachThread into getFront("thread"):
* console specifics:
  It would be similar with the console, where we always call attach/startListeners when we instanciate the front/client/actor:

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.
Blocks: 1495388
Blocks: 1495389
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.
Assignee: nobody → ystartsev
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
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
Attachment #9015580 - Attachment is obsolete: true
Attachment #9015575 - Attachment is obsolete: true
Attachment #9015568 - Attachment is obsolete: true
Attachment #9017131 - Attachment is obsolete: true
Attachment #9017129 - Attachment is obsolete: true
Pushed by
introduce async front instantiation; r=ochameau
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Whiteboard: dt-fission
Blocks: 1503562
You need to log in before you can comment on or make changes to this bug.