1762334 - Use EventsDispatcher to subscribe to all MessageHandler events in the root layer

Status: RESOLVED FIXED

(Remote Protocol :: Agent, task, P1)

Description

[Julian Descottes [:jdescottes]]

This is a follow up to the discussion at https://phabricator.services.mozilla.com/D141583?id=560866#inline-784526

The goal is to create a class that simplifies subscribing to events, potentially from multiple consumers, ensuring we only add and remove the actual platform listeners when needed.

This is challenging because events can follow different subscription logic and can originate from different processes.

We have two types of events in the MessageHandler framework: protocol events and internal events. Protocol events should follow the specs for the session.subscribe command, which means they don't really behave like a add/removeEventListener API. Whereas for internal events, we usually want a typical add/remoteEventListener behavior.

Those events can come from the parent process (eg browsingContext.contextCreated) or from content processes (eg browsingContext.domContentLoaded). When the events come from the content process, we usually have to set them up using SessionData. However for parent process events, they can bypass SessionData (that's the case for contextCreated right now).

And finally, those events usually rely on listener classes which provide a consistent API (start/stop/on/off) right on top of platform events. The listener class therefore lives right next to where the event is created. But we can have a single listener responsible for emitting several events. Typically browsingContext.contextDestroyed could be handled by the same listener class as browsingContext.contextCreated. In that case, calling start or stop depends on how the consumer wants to listen to 2 different events.

It's not clear if this should only be addressed with a single "helper", and I think we should also discuss:

• which data should be in session data
• should we allow to count references for some session data
• should listener classes accept optional arguments to start/stop to do lightweight ref counting

Comment 1

[Julian Descottes [:jdescottes]]

This could be helpful to get sorted out before handling Bug 1694390

Comment 2

[Julian Descottes [:jdescottes]]

Moving back to the backlog

Comment 3

[Julian Descottes [:jdescottes]]

Based on the current work in Bug 1783177, updating the summary.

We no longer distringuish internal and protocol events. However, not all the consumers of events in the root module are using the EventsDispatcher yet. In particular, the session module is directly listening to message handler events (this.#messageHandler.on) after Bug 1783177.

It should use the EventsDispatcher instead.

Comment 4

[Julian Descottes [:jdescottes]]

Attachment: Bug 1762334 - [messagehandler] Remove _subscribe/_unsubscribeEvent commands in favor of SessionData

Depends on D155061

All events now only react to SessionData and the session module can directly add/remove session data instead of using internal commands.
In the next patch, it will start relying on EventsDispatcher directly.

Comment 5

[Julian Descottes [:jdescottes]]

Attachment: Bug 1762334 - [messagehandler] Use EventsDispatcher in session module

Depends on 1762334

Some additional corrections had to be made on the EventsDispatcher module at the same time.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/025507e99cbf
[messagehandler] Remove _subscribe/_unsubscribeEvent commands in favor of SessionData r=webdriver-reviewers,whimboo
https://hg.mozilla.org/integration/autoland/rev/eb78ce4eb12a
[messagehandler] Use EventsDispatcher in session module r=webdriver-reviewers,whimboo

Comment 7

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/025507e99cbf
https://hg.mozilla.org/mozilla-central/rev/eb78ce4eb12a