When remote.log.level is Log.Level.Info or above, verbose logging
is enabled and we pretty-print JSON payloads in requests to the
HTTPD in JSONHandler.
This patch matches the behaviour of the JSONHandler logging, where
JSON payloads are logged to stdout with special formatting before
being transmitted across WebSocket connections.
Differential Revision: https://phabricator.services.mozilla.com/D58506
--HG--
extra : moz-landing-system : lando
Errors that arise from use of the protocol, for example by the client
passing in the wrong argument or an operationg being unsupported, are
returned to the client. Since these are not inherent implementation
problems there is no point to double-logging them in the server.
This is a left-over from when the remote agent was in a prototype
stage and we couldn't always rely on the Puppeteer client to
interact with Firefox correctly.
Differential Revision: https://phabricator.services.mozilla.com/D58508
--HG--
extra : moz-landing-system : lando
When remote.log.level is Log.Level.Info or above, verbose logging
is enabled and we pretty-print JSON payloads in requests to the
HTTPD in JSONHandler.
This patch matches the behaviour with JSON payloads being transmitted
across WebSocket connections.
Differential Revision: https://phabricator.services.mozilla.com/D58506
--HG--
extra : moz-landing-system : lando
As long as we do not validate incoming messages against the
Chrome DevTools JSON schema, all incoming commands would be
executed. To prevent clients from changing internal data by
calling internal commands (prefixed with "_"), deny their
execution.
Differential Revision: https://phabricator.services.mozilla.com/D55411
--HG--
extra : moz-landing-system : lando
This event is currently sent for each and every message,
and as such duplicates every log entry as displayed when
having the Puppeteer debug logs turned on.
Until we can fix it to behave correctly, it should be
disabled.
Differential Revision: https://phabricator.services.mozilla.com/D54273
--HG--
extra : moz-landing-system : lando
Connection already saves the list of Session, so it is more natural
to save it only once there and instead directly close the connections
from Target. Each connection is going to cleanup all related sessions.
I also stop automatically registering the session to the connection from Session constructor,
it felt not explicit enough.
Differential Revision: https://phabricator.services.mozilla.com/D37045
--HG--
extra : moz-landing-system : lando
This helps sharing a single implementation of how the JSON objects
are read and written from/to the WebSocket connection.
Also, by delegating the command calls to the Session via `Session.execute`
and expecting a promise with a resolution or rejection, we make error
handling of command calls clearer and unified.
Differential Revision: https://phabricator.services.mozilla.com/D37046
--HG--
extra : moz-landing-system : lando
This fixes the browser mochitest which currently timesout when calling server.close()
It started to timeout when the patch related to websocket handshake landed.
Depends on D24219
Differential Revision: https://phabricator.services.mozilla.com/D24220
--HG--
extra : moz-landing-system : lando
In order to be able to query/instantiate sub targets like remote frames, or tab targets from the MainProcessTarget,
we have to support session at the protocol layer.
This is all based on a `sessionId` attribute put on all inbound/outbound messages.
This patch will be later used, once we start instantiating sub targets.
Differential Revision: https://phabricator.services.mozilla.com/D22694
--HG--
extra : moz-landing-system : lando
This was breaking the constructor name, used in Domain.jsm.
As doing
this.Foo = class extends Domain {
creates a class with undefined constructor name.
While
class Foo extends Domain {
creates a class with "Foo" as domain name.