Due to some obvious bugs in the code of TabObserver.jsm the registered
targets for each of the window's tabs haven't been unregistered when
the window has been closed.
It has the effect that when closing the Remote Agent the browsingContext
of the tab target, which has to be destroyed, cannot be retrieved.
Instead an error is raises, because the underlying frameLoader actually
doesn't exist anymore.
Given that "TabClose" events aren't fired when the window closes,
those have to be emulated.
Differential Revision: https://phabricator.services.mozilla.com/D50231
--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
* TabObserver is rather an helper class of Targets rather than RemoteAgent.
Targets is the class which holds all the targets and reports about their
creation and destructor. It feels legitimate to have it directly integrate
with TabObserver.
* To better sort of the files. i.e. avoid having "random files" in /remote/
I'm renaming and moving TabObserver according to its usage.
* We were emitting "connect" and "disconnect" event when a target was created
or destroyed. But this is misleading as there is no connection to anything
being made. Only later, a CDP client might connect to a target HTTP endpoint
and initiate a connection. These events are making this hard to understand
that the connection actually happens when Target.handle is called.
Differential Revision: https://phabricator.services.mozilla.com/D37043
--HG--
rename : remote/WindowManager.jsm => remote/targets/TabObserver.jsm
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
Connect and disconnect in misleading here as a target aren't connected/disconnected,
but instead, being unregistered and destroyed. The fact that they are "disconnected"
is a side effect of this destruction. Also note that a Target is never "connected",
it is only a Connection and its related sessions which really are connected to a remote client.
Differential Revision: https://phabricator.services.mozilla.com/D37042
--HG--
extra : moz-landing-system : lando
This will later help register the component statically in bug 1536862.
And already ease using the remote agent from other JSM files.
Differential Revision: https://phabricator.services.mozilla.com/D24227
--HG--
rename : remote/RemoteAgent.js => remote/RemoteAgent.jsm
extra : moz-landing-system : lando
Doing this helps fixing the main target's path which is meant to be:
/devtools/browser
Depends on D24220
Differential Revision: https://phabricator.services.mozilla.com/D24221
--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 this revision it only helps sharing `handle`.
But in a followup changeset, it will also help closing all the connections
and justify the `sessions` map we keep around.
Differential Revision: https://phabricator.services.mozilla.com/D24219
--HG--
rename : remote/targets/MainProcessTarget.jsm => remote/targets/Target.jsm
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
Introduces a new kind of target "main-process",
which is not bound to any particular browser-element/browsing-context.
This implements only a subtest of domains and typical won't support the "content" ones.
This will require some more work in order to acknowledge having multiple kinds of targets.
We will also have "worker", "addon" and remoted-frames which will be very similar to tabs.
Depends on D22690
Differential Revision: https://phabricator.services.mozilla.com/D22691
--HG--
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
This is going to help introduce multiple kind of targets.
Depends on D22685
Differential Revision: https://phabricator.services.mozilla.com/D22686
--HG--
rename : remote/Target.jsm => remote/targets/Target.jsm
rename : remote/Targets.jsm => remote/targets/Targets.jsm
extra : moz-landing-system : lando
Andreas Tolfsen
Henrik Skupin
Boris Zbarsky
Alexandre Poirot
shindli
Victor Porof