The Marionette server handles requests separately with a global sense
of state which makes it hard to introduce generalised behaviour to many
commands. This effectively slows down protocol implementation because
each command request individually needs to do heavy lifting.
This patch introduces a series of abstractions that separates out the
WebDriver implementation to a new class, GeckoDriver. It also features
a new interface to mediate messages between the chrome- and content
processes.
This allows the code living in the chrome context to make direct calls
on the listener through a promise-based API:
let listener = new ListenerProxy(mm, sendCallback);
let res = yield listener.functionOnListener("arg1", "arg2");
The MarionetteServer class that used to live in marionette-server.js
has now been moved to server.js, while the WebDriver implementation
has moved to driver.js. By introducing more stringent separation,
MarionetteServer now properly encapsulates the server process allowing
us to unit tests for it in the future.
The patch is a refactor in the truest sense, in the meaning that no
input or output should have changed.
--HG--
extra : rebase_source : c94b8cd6b4e61addd3fe42c4b94a26ee987fc34a
extra : source : 7f506cdb77b88994ba9f5b13cc936a99a403f1fb
The dispatcher is analogous to the client socket connection, and handles
receiving packets and closing connections.
It also encompasses some of the functionality needed to establish the
devtools and Marionette connection, that previously used to live in
MarionetteServerConnection in marionette-server.js.
For each connection, recognised commands will be forwarded to the command
processor (command.js) unless a handler is defined in Dispatcher.requests.
--HG--
extra : rebase_source : 13cc697ba45addb6191df7d2f7ea1133194177ce
extra : source : 7abef4010b3094d3f276fc16cfbae43b55da7b0d
The command processor receives messages, processes them, and wraps the
execution of the command implementations. This allows commands to throw
errors without worrying about the side effects.
This patch also introduces a Response object which correspondingly wraps
the replies to the client. This shifts the responsibility of managing
the correctness of the packets from the commands to this.
--HG--
extra : rebase_source : 92e0ee1b3f7034a548a8a36705504b307906cf23
extra : source : b0d00faceef4e348cc99c020f01d59c7933677b7
Adds the ability to throw error objects for WebDriver statuses, and an
error module with convenience functions for manipulation of these and
for handling other error related operations.
--HG--
extra : rebase_source : 5ee047fd7a8e0ecea918e422cd12273b78a78153
extra : source : 0c074cdc434e3c8ba412db44aece7b1840198fe5
The Marionette server handles requests separately with a global sense
of state which makes it hard to introduce generalised behaviour to many
commands. This effectively slows down protocol implementation because
each command request individually needs to do heavy lifting.
This patch introduces a series of abstractions that separates out the
WebDriver implementation to a new class, GeckoDriver. It also features
a new interface to mediate messages between the chrome- and content
processes.
This allows the code living in the chrome context to make direct calls
on the listener through a promise-based API:
let listener = new ListenerProxy(mm, sendCallback);
let res = yield listener.functionOnListener("arg1", "arg2");
The MarionetteServer class that used to live in marionette-server.js
has now been moved to server.js, while the WebDriver implementation
has moved to driver.js. By introducing more stringent separation,
MarionetteServer now properly encapsulates the server process allowing
us to unit tests for it in the future.
The patch is a refactor in the truest sense, in the meaning that no
input or output should have changed.
--HG--
extra : rebase_source : 2513f6e88b79b2420757e66890d5ca49d5266318
The dispatcher is analogous to the client socket connection, and handles
receiving packets and closing connections.
It also encompasses some of the functionality needed to establish the
devtools and Marionette connection, that previously used to live in
MarionetteServerConnection in marionette-server.js.
For each connection, recognised commands will be forwarded to the command
processor (command.js) unless a handler is defined in Dispatcher.requests.
--HG--
extra : rebase_source : 2cf2e3ab1ab8b1044aff798b461dfee9b08cf7a4
The command processor receives messages, processes them, and wraps the
execution of the command implementations. This allows commands to throw
errors without worrying about the side effects.
This patch also introduces a Response object which correspondingly wraps
the replies to the client. This shifts the responsibility of managing
the correctness of the packets from the commands to this.
--HG--
extra : rebase_source : cfab78a0919b0cc95db9dfdf47b2b5e29a15094b
Adds the ability to throw error objects for WebDriver statuses, and an
error module with convenience functions for manipulation of these and
for handling other error related operations.
--HG--
extra : rebase_source : 8095e97f974cdf157cb3100a4249a6ae1a6451dc
Some mochitests needs to behave differently when ran on B2G Desktop.
Currently, this is implemented using user agent string detection,
mostly relying on "Mobile" being present and "Android" being absent.
This is only true on B2G Desktop when ran on Try because the mozconfig
defined FXOS_SIMULATOR and that, per bug 1115935, this substring is only
added in this case, but not if just MOZ_B2G is defined. A better
approach is to expose 'isB2G' in SpecialPowers for this kind of
detection.
