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
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 change removes almost all the remaining uses of loadSubScript and
global scope pollution. The only remaining use is for common.js, which
is resolved by a later bug for evaluating scripts.
MozReview-Commit-ID: 96h0yLElauq
--HG--
extra : histedit_source : 70f70a8aeffef3fca18addfa3fca575a9128e11a
extra : rebase_source : c251c58a7a086c606d3d3941adfeee26ecc49504
extra : commitid : 8XlX4zVZQUN
extra : source : 6bb93562a57656e6cc744c3c901a5ec80f9ec4d8
extra : intermediate-source : ad5bf32d8fef351a0bc4d6249bd16a34aa83f548
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 change removes almost all the remaining uses of loadSubScript and
global scope pollution. The only remaining use is for common.js, which
is resolved by a later bug for evaluating scripts.
MozReview-Commit-ID: 96h0yLElauq
--HG--
extra : commitid : 8XlX4zVZQUN
extra : rebase_source : a5c8057c7ce0f52dc319f2e9d0937d6a4aab84d4
extra : source : 6bb93562a57656e6cc744c3c901a5ec80f9ec4d8
extra : histedit_source : 70f70a8aeffef3fca18addfa3fca575a9128e11a
This does not appear to be in use.
--HG--
extra : commitid : I8NVDyxCC0e
extra : rebase_source : 757f75ecd813873513fb9bd56625c59d3d0936b3
extra : histedit_source : 241a896d0701c529cf56636eff567211198839cb
This change removes almost all the remaining uses of loadSubScript and
global scope pollution. The only remaining use is for common.js, which
is resolved by a later bug for evaluating scripts.
--HG--
extra : commitid : 8XlX4zVZQUN
extra : rebase_source : b5420c4ba5298a7e972e7b14a13325bb8ea1a540
extra : histedit_source : 70f70a8aeffef3fca18addfa3fca575a9128e11a
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
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
In a following patch, all DevTools moz.build files will use DevToolsModules to
install JS modules at a path that corresponds directly to their source tree
location. Here we rewrite all require and import calls to match the new
location that these files are installed to.
--HG--
extra : commitid : F2ItGm8ptRz
extra : rebase_source : b082fe4bf77e22e297e303fc601165ceff1c4cbc
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
Andreas Tolfsen
Karl Tomlinson
David Burns
Carsten "Tomcat" Book
Wes Kocher
Nigel Babu
Sebastian Hengst
J. Ryan Stinnett
Shu-yu Guo
Jonathan Griffin