Domains would have created their own instance of the context observer,
which results in duplicated event listeners and observer notifications
to be registered.
This is still not ideal for the observer notifications, which should be
registered only once, but still an improvement for now. Bug 1635568 will
finally fix that.
Differential Revision: https://phabricator.services.mozilla.com/D74632
To better keep track of available observer classes
it's better to have them all in the same folder.
While moving files around the patch also renames
the TabObserver module to TargetObserver, which
would allow us to add target observers for workers
in the future.
Differential Revision: https://phabricator.services.mozilla.com/D73042
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
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
This moves the assertions related to the well-formedness of the method
from the TabSession consumer to Domains.splitMethod. Following the
introduction of TabSession, this was missing from the superclass Session.
This also fixes the "Foo.bar.baz" test case in
remote/test/unit/test_Domains.js by removing the split() function
and instead relying on String#split() inside Domains.splitMethod.
Thanks-to: Alexandre Poirot <ochameau@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D25947
--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
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
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
Henrik Skupin
Maja Frydrychowicz
Andreas Tolfsen
Alexandre Poirot
Victor Porof
Brindusan Cristian
Julian Descottes