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
We return with this rather omnious message when we are missing the
implementation of a CDP method:
Error: Protocol error (Target.createBrowserContext): TypeError: inst[command] is not a function:
This patch improves the error message so that debugging is not
necessary to find out which domain or command is missing.
Ideally Session.jsm and ContentProcessSession.jsm would share the
same execute() function (there's really not reason they don't),
but that involves more work.
Differential Revision: https://phabricator.services.mozilla.com/D32069
--HG--
extra : source : f3d44dbce7e3d1b529ce37b21a4d7471a918edd4
extra : histedit_source : df4d534565efb3e2babbc277a3aecce5d534ac39
We return with this rather omnious message when we are missing the
implementation of a CDP method:
Error: Protocol error (Target.createBrowserContext): TypeError: inst[command] is not a function:
This patch improves the error message so that debugging is not
necessary to find out which domain or command is missing.
Ideally Session.jsm and ContentProcessSession.jsm would share the
same execute() function (there's really not reason they don't),
but that involves more work.
Differential Revision: https://phabricator.services.mozilla.com/D32069
--HG--
extra : moz-landing-system : lando
The remote agent currently uses "method" interchangably for the
full method string as extracted from JSON input as well as for the
function part following the first dot after the method has been split.
To avoid namespace clashes, this patch makes a distinction between
method, being the input JSON field; the first substring prior to the
dot being the domain; and the rest that follows being called the command:
method = "<domain>.<command>"
This naming seems to be supported by chrome-remote-interface:
https://github.com/cyrus-and/chrome-remote-interface/blob/master/lib/api.js#L32
Differential Revision: https://phabricator.services.mozilla.com/D25946
--HG--
extra : moz-landing-system : lando
A session is bound to a browsing context, not just one document.
`unload` is fired when navigating to another document. The document goes
away, but not the browsing context. So, we should keep the session up and running
when the current document is destroyed and we navigate to another URL.
Depends on D25577
Differential Revision: https://phabricator.services.mozilla.com/D25578
--HG--
extra : moz-landing-system : lando
The Session used by MainProcessTarget isn't bound to any browser-element
and so do not use any of the message manager to pipe message to the content process.
Same for Target, the MainProcessTarget doesn't expose any browsing-context-related attribute.
Depends on D22691
Differential Revision: https://phabricator.services.mozilla.com/D22692
--HG--
rename : remote/sessions/Session.jsm => remote/sessions/TabSession.jsm
rename : remote/targets/Target.jsm => remote/targets/TabTarget.jsm
extra : moz-landing-system : lando
This is going to help have different kind of session par target kind.
Depends on D22686
Differential Revision: https://phabricator.services.mozilla.com/D22687
--HG--
rename : remote/ContentProcessSession.jsm => remote/sessions/ContentProcessSession.jsm
rename : remote/Session.jsm => remote/sessions/Session.jsm
rename : remote/frame-script.js => remote/sessions/frame-script.js
extra : moz-landing-system : lando