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
By resolving localhost to an actual IP for the httpd.js server
allows us to supply unique URLs for the CDP and WebDriver BiDi
WebSocket connection details and CDP's JSON handler end-points.
Hereby the first resolved IP will be used which should always be
the local IPv4 address (127.0.0.1). If IPv4 is disabled `[::1]`
will be used.
It will prevent issues especially on dualstack systems where DNS
resolution might prefer IPv6 over IPv4 (like with node.js > 16).
Differential Revision: https://phabricator.services.mozilla.com/D154151
Touch is a bit different to mouse inputs because there are often
multiple pointers (i.e. fingers) acting at the same time. It turns out
that Gecko wants a single call containing all the positions etc. of
the touch pointers for each event, rather than having a single call
per pointer. So we have to group the pointer actions from one tick
together.
Differential Revision: https://phabricator.services.mozilla.com/D139120
If a reftest times out we close the window before the following
test. However because we weren't waiting for this close to complete
there was a race condition where the following test would fail with a
"browsing context was discarded".
Ensuring that we wait for the window to close in `abort` seems to be
sufficient to fix this issue.
Differential Revision: https://phabricator.services.mozilla.com/D151918
Initializing CDP before the first window has been opened can break
the registration of the first browser window because a pre-loaded
window gets opened first before the gBrowser is attached.
This also prevents any CDP client to connect to any the JSONHandler
end-points before CDP is actually ready.
Differential Revision: https://phabricator.services.mozilla.com/D151843
Touch is a bit different to mouse inputs because there are often
multiple pointers (i.e. fingers) acting at the same time. It turns out
that Gecko wants a single call containing all the positions etc. of
the touch pointers for each event, rather than having a single call
per pointer. So we have to group the pointer actions from one tick
together.
Differential Revision: https://phabricator.services.mozilla.com/D139120
Touch is a bit different to mouse inputs because there are often
multiple pointers (i.e. fingers) acting at the same time. It turns out
that Gecko wants a single call containing all the positions etc. of
the touch pointers for each event, rather than having a single call
per pointer. So we have to group the pointer actions from one tick
together.
Differential Revision: https://phabricator.services.mozilla.com/D139120
