Closed Bug 1495387 Opened 1 year ago Closed 1 year ago

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

Categories

(DevTools :: Framework, enhancement, P2)

enhancement

Tracking

(firefox64 fixed)

RESOLVED FIXED
Firefox 64
Tracking Status
firefox64 --- fixed

People

(Reporter: ochameau, Assigned: yulia)

References

(Blocks 2 open bugs)

Details

(Whiteboard: dt-fission)

Attachments

(1 file, 5 obsolete files)

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.
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
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
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 ystartsev@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a6b4461eadf0
introduce async front instantiation; r=ochameau
https://hg.mozilla.org/mozilla-central/rev/a6b4461eadf0
Status: NEW → RESOLVED
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.