1788760 - Support a new session data category to automatically enable modules on MessageHandler startup

Status: NEW

(Remote Protocol :: Agent, task, P2)

Description

[Julian Descottes [:jdescottes]]

As of today, any module which has a matching session-data item when a MessageHandler starts will be automatically instantiated.

For instance if you listen for log.entryAdded on all windowglobal contexts, any windowglobal MessageHandler will automatically spawn a log module on startup.

However it could be useful to have another session data item category, not tied to events, which would just trigger the instantiation of the module. Imagine a module in which we want to start building a cache which would be difficult to create on the fly. It would be great if this module could start immediately, without generating unnecessary events.

The proposal is to have session data items such as

{
      moduleName,
      category: "enabledModules",
      contextDescriptor: {
        type: lazy.ContextDescriptorType.All,
      },
      values: [moduleName]
}

In this example values is redundant with the session data item's module name ... I guess we could also leave it empty, although this might have some more impacts on the framework.

We could also discuss about having session data items which are not owned by a module, so that we could have a unique session data item, with the list of modules in the values property, but I'd prefer to keep a consistent design for the items. It's not a big deal if values here is a bit irrelevant.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This will specifically be important when we want to start using events only sent internally for certain things like populating a realm cache in the parent process. Hereby the script module would have to automatically send such an event to announce the creation of the realm for the default window global. Other module might become important as well.

Comment 2

[Julian Descottes [:jdescottes]]

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #1)

This will specifically be important when we want to start using events only sent internally for certain things like populating a realm cache in the parent process. Hereby the script module would have to automatically send such an event to announce the creation of the realm for the default window global. Other module might become important as well.

Note that thanks to the recent refactors, internal events are also handled in session data. So if the goal is to listen to an internal event, simply subscribing to it from the root layer will have the desired effect. I guess there's a question of what's most explicit between subscribing to an event and just saying "script should be always enabled". But technically speaking this would only be required if we want to start a module without sending events (even internal ones) immediately.