Emulator callbacks are now created dynamically upon request, and uses
a nicer data structure in chrome context. Each emulator callback is
encapsulated in EmulatorCallback, and stored on Emulator.
Emulator is stored on Dispatcher (as opposed to in marionette-server.js)
which bypasses some of the problems with circumventing the Marionette
protocol in GeckoDriver because of CommandProcessor.
Emulator callbacks to the client should be considered transparent, hence
they do not use the ListenerProxy. They are explicitly meant _not_
to be blocking.
--HG--
extra : rebase_source : 9e887526af99c02036575e5c7b6790629d5f917d
extra : source : eeb3d39874b17e02888427afb9709f35abc95120
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 : 72c68105df19dc1e328f78c6bfb2282b61d82c8d
extra : source : 7f506cdb77b88994ba9f5b13cc936a99a403f1fb
Emulator callbacks are now created dynamically upon request, and uses
a nicer data structure in chrome context. Each emulator callback is
encapsulated in EmulatorCallback, and stored on Emulator.
Emulator is stored on Dispatcher (as opposed to in marionette-server.js)
which bypasses some of the problems with circumventing the Marionette
protocol in GeckoDriver because of CommandProcessor.
Emulator callbacks to the client should be considered transparent, hence
they do not use the ListenerProxy. They are explicitly meant _not_
to be blocking.
--HG--
extra : rebase_source : cc936f6556b666ac68f7cc5040c1772b74a0dd66
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
