Depends on D177181
Quick summary:
Handling a command is mostly done in 2 steps
- first check if there is a module in the current layer which matches the command
- if yes: send the command to this module, if no: try to forward the command (using forwardCommand which has different implementations for each message handler)
The initial patch to allow windowglobal -> root communication was flawed, because it updated the ModuleCache to return "root" modules when the destination was of type ROOT. However that's not how MessageHandler modules are supposed to work. The ModuleCache should only ever return modules which can be loaded in the current "layer". So if we are in a windowglobal ModuleCache, we should never return a "root" module.
Instead the ModuleCache should return (and store) `null` for this load attempt, so that the MessageHandler can go to the `forwardCommand` step.
So here I slightly changed the ModuleCache implementation to have a single `#getModuleClass` private helper, which can quickly check if we are in a "not root" -> "root" scenario and just return null early.
Follow up: I think some of the logic currently kept in the module cache should move to the MessageHandler, and the ModuleCache should only care about caching module classes/instances. All the destination-to-folder logic is really tied to handling commands, so that should be done by the base MessageHandler class. Or at least it should be closer to the `handleCommand` implementation.
Differential Revision: https://phabricator.services.mozilla.com/D177202
The current test had complicated logic in the test module "command.sys.mjs" which means we were asserting the test module more than the actual behavior of MessageHandler/SessionData.
Instead, we use a simpler test module, and precisely assert all the updates we receive for session data updates. Also taking the opportunity to add some tests when updating session data items from several categories.
Differential Revision: https://phabricator.services.mozilla.com/D166969
Depends on D155059
In order for all events to really use similar codepaths, they should not use different subscription mechanism.
Setting an event in SessionData should be the entry point for all modules to decide to update their listeners or not.
Therefore we will also call _applySessionData on root modules which support this.
Next patch will start using this for the browsingContext.contextCreated event.
Differential Revision: https://phabricator.services.mozilla.com/D155060
The current version returns the return value of the command (which can be a broadcast, depending on the provided descriptor).
This makes it impossible to know what to consistently expect as a return value.
It seems it was only used for a test assertion, so rewrite the test and cleanup the return value
Differential Revision: https://phabricator.services.mozilla.com/D155059
We no longer distinguish between internal and protocol events within the framework.
All events now have the same behavior:
- emitted both under their own name and under the name message-handler-event
- bubble up to the root message handler
- the session which owns the RootMessageHandler does not listen for those events
The emitProtocolEvent has been moved to the RootMessageHandler only and can be used to emit events under a specific name "message-handler-protocol-event".
Only those events will be sent over to the actual client.
Internally the session module now keeps track of which events have already been subscribed to, to avoid forwarding duplicated events.
In a followup this will be centralized over in the EventsDispatcher, which can now play a bigger role.
Note that in the same way as for commands, there is still an implicit notion of "internal event", as in "an event which can not be subscribed to by consumers".
For commands this is done by having a "_" before the command name.
For events this is done by listing or not the event in the "supportedEvents" static array of the Module.
Differential Revision: https://phabricator.services.mozilla.com/D155025
Depends on D147713
This adds a "retryOnAbort" property on MessageHandler Commands.
When set to true, this will allow the FrameTransport to retry a command up to 10 times in case of an AbortError.
Difference with Marionette, this doesn't attempt to detect BrowsingContexts in bfcache, because retrying commands
does not make sense in bfcache (this is not a temporary state, retrying in a loop will most likely not help).
A browser mochitest is added to cover various retry scenarios.
Differential Revision: https://phabricator.services.mozilla.com/D147715
Depends on D138523
Given our current broadcast logic, we should not stumble on webextension contexts during broadcast.
This is because getAllBrowsingContextsInSubtree will not cross process boundaries.
Nevertheless, adding explicit support for WebExtensions in our filter method should be ok, with the added test.
Whenever we lift the JSWindowActor restrictions and rely on isBrowsingContextCompatible for filtering this will help avoid regressions.
Differential Revision: https://phabricator.services.mozilla.com/D138531
We are not supporting the TOP_BROWSING_CONTEXT yet in BiDi, but message handler already supports it, and assumes browser ids. But as discussed we will need to use custom UUIDs, and on the side have a mapping between browser ids and UUIDs, as browserids might be available late.
Differential Revision: https://phabricator.services.mozilla.com/D135414
Before an instance of a WindowGlobalMessageHandler is ready to be used the
initial session data needs to be applied. Because this happens asynchronously
an internal "window-global-handler-created" event will be used for which the
root message handler or any other module can listen for.
Differential Revision: https://phabricator.services.mozilla.com/D134265
There are two kind of events that can be used by module implementations
to pass information within the message handler framework.
First, with internal events the different modules and the message handlers
themselves can send around information eg. informing the parent process
about specific DOM events happening in the child process. These events
are not intended to be sent to external clients.
Second, with protocol events the different modules can send events with
a payload as specified in the appropriate protocol. These events shouldn't
be intercepted, modified, or ignored and will be sent to external clients.
Differential Revision: https://phabricator.services.mozilla.com/D134264
Depends on D132150
Adds a new API to RootMessageHandler which will be necessary to implement _unsubscribeEvent on root/log.jsm
Expand the current browser mochitest for session data to cover the new API.
Differential Revision: https://phabricator.services.mozilla.com/D132152
