This does not appear to be in use.
MozReview-Commit-ID: B4M335Lb1UM
--HG--
extra : histedit_source : 241a896d0701c529cf56636eff567211198839cb
extra : rebase_source : 0b30f291ed1aee3f4073f2fea47ac4d9c6a6a576
extra : commitid : I8NVDyxCC0e
extra : source : 22321e6b65e987a76e42f880c8aa5a0427052259
extra : intermediate-source : 3b9e9a027fa7f020ac80c060938488f53f61049c
This does not appear to be in use.
MozReview-Commit-ID: B4M335Lb1UM
--HG--
extra : commitid : I8NVDyxCC0e
extra : rebase_source : be6fddfe28cbe626114c38416c97075ee5cdf3a4
extra : source : 22321e6b65e987a76e42f880c8aa5a0427052259
extra : histedit_source : 241a896d0701c529cf56636eff567211198839cb
This does not appear to be in use.
--HG--
extra : commitid : I8NVDyxCC0e
extra : rebase_source : 757f75ecd813873513fb9bd56625c59d3d0936b3
extra : histedit_source : 241a896d0701c529cf56636eff567211198839cb
Message sequencing allows Marionette to provide an asynchronous,
parallel pipelining user-facing interface, limit chances of payload
race conditions, and remove stylistic inconsistencies in how commands
and responses are dispatched internally.
Clients that deliver a blocking WebDriver interface are still be expected
to not send further command requests before the response from the last
command has come back, but if they still happen to do so because of
programming error or otherwise, no harm will be done. This will guard
against bugs such as bug 1207125.
This patch formalises the command and response concepts, and applies
these concepts to emulator callbacks. Through the new message format,
Marionette is able to provide two-way parallel communication. In other
words, the server will be able to instruct the client to perform a
command in a non ad-hoc way.
runEmulatorCmd and runEmulatorShell are both turned into command
instructions originating from the server. This resolves a lot of
technical debt in the server code because they are no longer special-cased
to circumvent the dispatching technique used for all other commands;
commands may originate from either the client or the server providing
parallel pipelining enforced through message sequencing:
client server
| |
msgid=1 |----------->|
| command |
| |
msgid=2 |<-----------|
| command |
| |
msgid=2 |----------->|
| response |
| |
msgid=1 |<-----------|
| response |
| |
The protocol now consists of a "Command" message and the corresponding
"Response" message. A "Response" message must always be sent in reply
to a "Command" message.
This bumps the Marionette protocol level to 3.
r=dburns
r=jgriffin
--HG--
extra : commitid : 1kz4Oa2q3Un
Message sequencing allows Marionette to provide an asynchronous,
parallel pipelining user-facing interface, limit chances of payload
race conditions, and remove stylistic inconsistencies in how commands
and responses are dispatched internally.
Clients that deliver a blocking WebDriver interface are still be expected
to not send further command requests before the response from the last
command has come back, but if they still happen to do so because of
programming error or otherwise, no harm will be done. This will guard
against bugs such as bug 1207125.
This patch formalises the command and response concepts, and applies
these concepts to emulator callbacks. Through the new message format,
Marionette is able to provide two-way parallel communication. In other
words, the server will be able to instruct the client to perform a
command in a non ad-hoc way.
runEmulatorCmd and runEmulatorShell are both turned into command
instructions originating from the server. This resolves a lot of
technical debt in the server code because they are no longer special-cased
to circumvent the dispatching technique used for all other commands;
commands may originate from either the client or the server providing
parallel pipelining enforced through message sequencing:
client server
| |
msgid=1 |----------->|
| command |
| |
msgid=2 |<-----------|
| command |
| |
msgid=2 |----------->|
| response |
| |
msgid=1 |<-----------|
| response |
| |
The protocol now consists of a "Command" message and the corresponding
"Response" message. A "Response" message must always be sent in reply
to a "Command" message.
This bumps the Marionette protocol level to 3.
r=dburns
r=jgriffin
--HG--
extra : commitid : 2upWRuXyqPF
extra : rebase_source : f384801e209e4b49ef57055fd550c3c435ece4ef
Moves most of the cookie implementation to a new file,
testing/marionette/cookies.js. The new Cookies class encapsulates all
APIs for manipulating and querying cookies from content space.
It communicates with chrome space, where the cookie manager lives, through
a new SyncContentSender provided by testing/marionette/proxy.js. This new
interface provides synchronous and transparent communication from content
to chrome, not dissimilar from how the original listener proxy works.
r=dburns
--HG--
extra : commitid : 7jF7OFSx4Yk
extra : rebase_source : 8fc73fb59196f8076e85673d002c42e2ae458ad0
In order to meet the addon signing requirement for tests, specialpowers
needs to be installed at gecko runtime. This means it must be restartless.
This patch packages specialpowers as a restartless addon, but it does not
yet install it at runtime.
--HG--
rename : testing/specialpowers/components/SpecialPowersObserver.js => testing/specialpowers/content/SpecialPowersObserver.jsm
extra : commitid : Bbg8gFten8S
extra : rebase_source : 99d0b841a1f8f9eb6b6ca846363a158836482e57
Errors thrown by takeScreenshot used to be silently ignored. When the
command started using the new dispatching technique in bug 1202663,
it was surfaced we do not support taking screen captures of SVG documents.
Since this is a requirement for Web Platform Tests, this patch corrects
the wrong assumptions about document body and document element.
This patch also significantly refactors the screen capture code, but
only uses the new implementation in contnent space, since some further
modifications are required to use it in chrome.
r=dburns
r=jgriffin
--HG--
extra : commitid : DdCIEpd5PEJ
extra : rebase_source : 7357010f992d7f995765c685000892cc59d9ec9a
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.
