To support realm events for shared and service workers - which can have more than 1 related context - we need to adapt our logic to match several browsing contexts to a single context descriptor.
On the bidi spec, this is expressed in the event is enabled algorithm (https://w3c.github.io/webdriver-bidi/#event-is-enabled )which takes an array of navigables as parameter. In order to enable this, a few event-related APIs are modified to support matching several browsing context ids.
We should be able to emit an event related to N contexts, and the event should be emitted if:
- any subscription monitors any of the related contexts
- any subscription monitors the user context of any of the related contexts
- any subscription is global
Note that this allows to emit an event related to 0 browsing contexts. In that case, global subscriptions should still get the event.
While this is handy given that we can't currently retrieve the contexts related to service and shared worker, this is also an important feature in the long run.
It is completely possible to have a worker instance for a service worker which. starts running even if no related context is open at the moment.
A dedicated browser mochitest is added to cover the new feature.
Differential Revision: https://phabricator.services.mozilla.com/D282748
This adds tests and framework support for vendored modules in MessageHandler
We also add the moz: prefix to the WebDriver BiDi ModuleRegistry
Differential Revision: https://phabricator.services.mozilla.com/D241233
This changeset updates the Parent JSWindowActor for MessageHandler to
send "ping" messages when a command takes more than 10 seconds to reply.
The "ping" message is expected to respond under 1 second, otherwise a warning
will be logged.
In the future, the JSWindowActor pair should be marked as blocked if the ping
fails and all pending commands should be canceled, future commands should be
rejected.
A browser mochitest is added to make sure the expected logs are generated.
Differential Revision: https://phabricator.services.mozilla.com/D239391
When attempting to send commands on a very early browsing context, the command might fail
due to a missing currentWindowGlobal.
This patch adds a helper to wait for the currentWindowGlobal property to be set and uses it from
RootTransport in order to avoid this issue.
A browser mochitest is added to cover this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D225281
The message handler framework now automatically retries executing
module methods in the window global if the corresponding
JSWindowActor pair is destroyed or becomes inactive.
This behavior can be disabled by setting the preference
"remote.retry-on-abort" to false, in which case retries
will only occur during the initial navigation.
Additionally, the behavior can be explicitly controlled
by individual callers by passing the "retryOnAbort" flag.
Differential Revision: https://phabricator.services.mozilla.com/D223398
BrowserTestUtils.loadURIString() is not async, nor returning a promise, it's
effectively not awaiting for the page to be loaded.
Differential Revision: https://phabricator.services.mozilla.com/D188211
BrowserTestUtils.loadURIString() is not async, nor returning a promise, it's
effectively not awaiting for the page to be loaded.
Differential Revision: https://phabricator.services.mozilla.com/D188211
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
Julian Descottes