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.
If special powers is imported using Components.utils.import on B2G which
has some special concepts around global scoping, a TypeError will be
raised unless the custom error is a prototypal Error.
An explanation can be found for a similar issue in bug 843892, which
states that toString is attached to the instances rather than the
prototype, and that this causes problems once the object goes through
Object.freeze. It was patched in bug 1014484.
This patch also renames SpecialPowersException to SpecialPowersError.
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.
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.
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.
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.
Although pause() is not yet asynchronous, any time we finish calling it the
ready promise should be resolved so we can safely wait on the ready promise
after calling pause already. This way, once pause() becomes async later in this
bug, code relying on this actor will continue to work.
Now that we have separate tests for checking the initial state of startTime we
can remove these checks from tests for setting the startTime.
Also, while we're at it, we needn't check the playState and animationPlayState
since these should be covered by other tests.
There are two callers of FlushDecoding - One is shutdown (where we already use
promises to wait for the queue to go idle via BeginShutdown), and the other is
dormant (see the comment).
Typically when GetAnimationRule is called, at least for CSS Animations, the
animation style rule will have been refreshed. However, in some cases such as
when the Web Animations API is used, the style rule will be marked as needing
to be refreshed outside of the usual flow. This rule will be refreshed when
nsAnimationManager::WillRefresh flushes animations but if the refresh driver
for the chrome document fires first, we will visit GetAnimationRule before
this happens.
This patch removes the assertion that expects animations to have been
refreshed by the time we reach GetAnimationRule causing it to update
the animation style rule as necessary.
