Provide facility for webchannel listeners to be loaded lazily




9 months ago
9 months ago


(Reporter: markh, Unassigned)


Firefox Tracking Flags

(Not tracked)




9 months ago
As part of bug 1353571 we are trying to improve the performance of loading the Firefox Accounts/Sync UI in the main window. One thing this code does is to create a webchannel for communication with

However, for the vast majority of users, this webchannel will never be used - but it is important that the channel be setup for the small number of users who do visit The same basic considerations apply to other webchannels created as the browser starts (eg, in NewTabWebChannel.jsm, in nsBrowserGlue.js, etc)

ISTM there could be value in having some kind of map "registry" of channel names mapped to a webchannel implementation. The WebChannel implementation may then be able to lazily initialize a handler upon receipt of the first message for that channel (and thus avoid loading *any* channel handlers for the vast majority of users)

As a straw-man, we could do something like bug 1252290 did for push - ie:

* Have webchannel listeners register an an xpcom service, and register with the category manager with the name of the channel.
* WebChannel.jsm, upon receipt of a message without a listener, looks up the category manager for a service registered with the channel name, and if it exists, instantiates the service.
* As part of service initialization, it must register the channel.
* WebChannel.jsm again looks for a listener, hopefully finds the newly registered one, and life continues.

It might be even better to invent our own registry somehow using JS modules or similar - it's just a straw-man to get the discussion started.

I don't know a great deal about the specifics of how WebChannels work but this sounds like a reasonable plan to me. I don't think there is a need to go the XPCOM route either, the category manager can be used with a list of JSM modules to load, the add-ons manager does this for loading custom add-on providers:

Comment 2

9 months ago
It turns out the main use-case we had for this found a different way to solve the problem, and without any other compelling use-cases, I think we should just close this.
Last Resolved: 9 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.