Open Bug 1677506 Opened 4 years ago Updated 4 years ago

Throw or log an error when protocol.js creates a front with an async "initialize" method

Categories

(DevTools :: General, task, P3)

task

Tracking

(Not tracked)

People

(Reporter: jdescottes, Unassigned)

References

Details

DevTools Fronts can implement an optional initialize method that will be automatically called by the framework after creating the front (at the manage step).

See Front::manage()

    if (typeof front.initialize == "function") {
      await front.initialize();
    }

https://searchfox.org/mozilla-central/rev/ff82c973f8ccb0475ec32439e9ec07014b3a681f/devtools/shared/protocol/Front.js#144-146

As you can see in the snippet above, front.initialize is in theory allowed to be async as we await on it.

However, depending on how the Front is created, we don't necessarily await on Front::manage(). This can lead to test issues with unhandled promise rejections, since there is no proper way to handle a rejection which would occur in this situation.

From what I could see, for Fronts created via getFront we await on the manage call.
https://searchfox.org/mozilla-central/rev/ff82c973f8ccb0475ec32439e9ec07014b3a681f/devtools/shared/protocol/types.js#550

For Fronts created via protocol.js, we don't await.
https://searchfox.org/mozilla-central/rev/ff82c973f8ccb0475ec32439e9ec07014b3a681f/devtools/shared/protocol/types.js#341

After discussing during the Tools checkin meeting, it is expected and async Fronts should not be created via protocoljs (and in general, we should really limit the amount of async fronts).

Consquently we should either throw or log an exception when we create a Front with an async initialize method in protocol js. We can still support initialize, but if it returns a promise, we should throw/log.

See Also: → 1677660
You need to log in before you can comment on or make changes to this bug.