The emulator code was originally hacks to allow us to instrument the emulator
from JavaScript in the B2G world. Since we no longer support this it is being
removed.
MozReview-Commit-ID: 3XDk21SFfUc
--HG--
extra : rebase_source : 63bc081c3ab37894b97b873fe142ee068b609318
In order to achieve WebDriver parity, Marionette needs the ability to
evaluate scripts in content space with lasting side-effects. This means
that state modifications should affect behaviour and state of the browsing
context, and such transgress the boundaries of the sandbox.
This patch brings a new script evaluation module that is shared between
code in chrome- and content space. This brings the number of unique
script evaluation implementations in Marionette down from six to one.
evaluate.sandbox provides the main entry-point for execution. It is
compatible with existing Marionette uses of Execute Script and Execute
Async Script commands in Mozilla clients, but also provides a new stateful
sandbox for evaluation that should have lasting side-effects.
It is not expected that Mozilla clients, such as testing/marionette/client
and the Node.js client in Gaia, should have to change as a consequence
of this change.
A substantial change to the script's runtime environment is that many
globals that previously existed are now only exposed whenever needed.
This means for example that Simple Test harness functionality (waitFor,
ok, isnot, is, &c.) is only available when using a sandbox augmented
with a Simple Test harness adapter.
Conversely, this patch does not expose marionetteScriptFinished as a
callback to asynchronous scripts for sandboxes which sandboxName parameter
is undefined, because this is what determines if the script should be
evaluated under WebDriver conformance constraints. In all other cases
where sandboxName _is_ defined, the traditional marionetteScriptFinished
et al. runtime environment is preserved.
MozReview-Commit-ID: 8FZ6rNVImuC
In order to achieve WebDriver parity, Marionette needs the ability to
evaluate scripts in content space with lasting side-effects. This means
that state modifications should affect behaviour and state of the browsing
context, and such transgress the boundaries of the sandbox.
This patch brings a new script evaluation module that is shared between
code in chrome- and content space. This brings the number of unique
script evaluation implementations in Marionette down from six to one.
evaluate.sandbox provides the main entry-point for execution. It is
compatible with existing Marionette uses of Execute Script and Execute
Async Script commands in Mozilla clients, but also provides a new stateful
sandbox for evaluation that should have lasting side-effects.
It is not expected that Mozilla clients, such as testing/marionette/client
and the Node.js client in Gaia, should have to change as a consequence
of this change.
A substantial change to the script's runtime environment is that many
globals that previously existed are now only exposed whenever needed.
This means for example that Simple Test harness functionality (waitFor,
ok, isnot, is, &c.) is only available when using a sandbox augmented
with a Simple Test harness adapter.
Conversely, this patch does not expose marionetteScriptFinished as a
callback to asynchronous scripts for sandboxes which sandboxName parameter
is undefined, because this is what determines if the script should be
evaluated under WebDriver conformance constraints. In all other cases
where sandboxName _is_ defined, the traditional marionetteScriptFinished
et al. runtime environment is preserved.
MozReview-Commit-ID: 8FZ6rNVImuC
--HG--
extra : rebase_source : 38cc7b1e374fd42afb213133fd1a5e11bf8bdd95
A distinct advantage is that try...catch statements are no longer used
to control the flow of code.
--HG--
extra : rebase_source : e3dcadcf9fdfcfe9d227b571b5a830437428762c
extra : source : 2b6d148fd941363e4580137e5d6efc0eebdaf7bd
A distinct advantage is that try...catch statements are no longer used
to control the flow of code.
--HG--
extra : rebase_source : 402890020719b04245aa7c601f52752cb43c0666
This change allows the logging level for Marionette to be set using
a preference. This lets an out-of-process program control Marionette's
logging level.
It also changes the logging defaults to print log messages with the level
Log.Level.Info and above for optimised builds, and Log.Level.Trace
and above for non-optimised/debug builds.
The log level can be set through the marionette.logging preference.
It holds a string value that needs to correspond to a level defined in
toolkit/modules/Log.jsm's Log.Level enum.
--HG--
extra : rebase_source : ef1cba2e26c3ad002bb1c28dac5654b68d02cb8f
Implementors and users find it better if we log the actual sent
and received packets, rather than a stringification of the messages
representing them.
--HG--
extra : rebase_source : 3a3137511cdd2f7e4fa7890b593db14e684b5a89
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
Introduce protocol version levels in the Marionette server.
On establishing a connection to a local end, the remote will return a
`marionetteProtocol` field indicating which level it speaks.
The protocol level can be used by local ends to either fall into
compatibility mode or warn the user that the local end is incompatible
with the remote.
The protocol is currently also more expressive than it needs to be and
this expressiveness has previously resulted in subtle inconsistencies
in the fields returned.
This patch reduces the amount of superfluous fields, reducing the
amount of data sent. Aligning the protocol closer to the WebDriver
specification's expectations will also reduce the amount of
post-processing required in the httpd.
Previous to this patch, this is a value response:
{"from":"0","value":null,"status":0,"sessionId":"{6b6d68d2-4ac9-4308-9f07-d2e72519c407}"}
And this for ok responses:
{"from":"0","ok":true}
And this for errors:
{"from":"0","status":21,"sessionId":"{6b6d68d2-4ac9-4308-9f07-d2e72519c407}","error":{"message":"Error loading page, timed out (onDOMContentLoaded)","stacktrace":null,"status":21}}
This patch drops the `from` and `sessionId` fields, and the `status`
field from non-error responses. It also drops the `ok` field in non-value
responses and flattens the error response to a simple dictionary with the
`error` (previously `status`), `message`, and `stacktrace` properties,
which are now all required.
r=jgriffin
--HG--
extra : commitid : FbEkv70rxl9
extra : rebase_source : 3116110a0d197289cc95eba8748be0a33566c5a5
Brings Marionette closer to compliance with the W3C WebDriver standard
which prescribes that errors should be identified by a string rather
than a magic number.
r=dburns
--HG--
extra : rebase_source : 2bdb28f3c05e56b17cc13ceacbf3167dabe89fd0
extra : source : 2b691bf191db1a83ae489116649602a74e64007a
Brings Marionette closer to compliance with the W3C WebDriver standard
which prescribes that errors should be identified by a string rather
than a magic number.
r=dburns
--HG--
extra : rebase_source : cde9ecded568fb17c46cd5940ec2241cd4446aaf
extra : source : 2b691bf191db1a83ae489116649602a74e64007a
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
Thomas Charles
David Burns
Andreas Tolfsen
Wes Kocher
Sebastian Hengst
Carsten "Tomcat" Book
Shu-yu Guo
Edgar Chen
Chris Manchester