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
Mainly manual fixes to fix issues found in the jsdoc comments now that they're recognised correctly.
Also removes some configuration that is no longer needed as it is now the default.
Differential Revision: https://phabricator.services.mozilla.com/D268569
Mainly manual fixes to fix issues found in the jsdoc comments now that they're recognised correctly.
Also removes some configuration that is no longer needed as it is now the default.
Differential Revision: https://phabricator.services.mozilla.com/D268569
All context ids handled by the events dispatcher are actual browsing context ids and not
TabManager UUIDs, there is no reason to use getBrowsingContextById here.
Differential Revision: https://phabricator.services.mozilla.com/D231971
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 isExtensionContext and isParentProcess browsing context helpers could throw if the
browsingContext did not have a valid currentWindowGlobal property.
Here we perform an early check on currentWindowGlobal from the only caller of those helpers, which
is isBrowsingContextCompatible. For this helper, it makes sense to return false if the browsing
context is not correctly attached yet. But it is more difficult to return a meaningful value
from isExtensionContext or isParentProcess, because those 2 helpers cannot assess the browsing
context correctly.
Differential Revision: https://phabricator.services.mozilla.com/D224238
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
Julian Descottes