Remote debugging server has a WebSocket option

[Jaroslav Šnajdr]

Hello everyone,

I am pleased to announce that bug 1286281 [1] has finally landed in m-c and
the Firefox remote debugging server can now run over the WebSocket
protocol. The command line to start a WebSocket server is:

firefox-bin --start-debugger-server ws:6080

This removes a major roadblock to implementing the devtools frontend using
standard Web APIs, which don't have access to raw TCP sockets, but do
support the WebSocket protocol.

The debugger.html project already has an option to connect directly to the
WebSocket server and avoid the TCP/WS proxy [2].

My thanks go mainly to J. Ryan Stinnett, who helped me with the devtools
debugger transport code, and to Jonas Sicking and Andrea Marchesini, who
reviewed my changes to the WebSocket implemenation in Necko and its WebIDL
bindings.

Jarda

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1286281
[2]
https://github.com/devtools-html/debugger.html/blob/master/config/development.json#L20

[Jan Odvarko]

This is great Jarda!

I noticed server/tests/mochitest/test_websocket-server.html test. Are there
any other examples showing how to connect to DevTools backend from
regular page? Where Debugger.html initiates the connection through WS?

Honza

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools

[Jaroslav Šnajdr]

Hello Honza!

Here is the code that establishes the connection to the WebSocket server in debugger.html:

https://github.com/devtools-html/debugger.html/blob/master/public/js/clients/firefox.js#L55-L58 <http://searchfox.org/mozilla-central/source/devtools/shared/security/tests/chrome/test_websocket-transport.html#44>

It does it in three steps:
1. Create the WebSocket object and connect it to the remote endpoint.
2. Create a debugger transport on top of the socket. The transport has a “send” method and “onMessage” handler for incoming packets. It works with JSON objects and transforms them into serialized bytes that are sent over the socket.
3. Create a DebuggerClient instance on top of the transport. This is the final object used by the rest of the frontend code to talk to the server. It’s aware of the actors etc.

The test you mention tests that the server and client part of the raw WebSocket connection work correctly. It knows nothing about the debugger protocol. You might want to look at another test, which tests the transport and the DebuggerClient:

http://searchfox.org/mozilla-central/source/devtools/shared/security/tests/chrome/test_websocket-transport.html#41-48 <http://searchfox.org/mozilla-central/source/devtools/shared/security/tests/chrome/test_websocket-transport.html#41-48>

This code does the same steps as the debugger.html code above, only the steps 1 and 2 are wrapped inside the DebuggerClient.socketConnect function.

Jarda

[J. Ryan Stinnett]

Thanks again for working on this Jarda! It should open up many new ways to
connect to the tools from web content, so it's exciting to have this in
place.

- Ryan

[Joe Walker]

Yes, thanks Jarda. Impressive piece of work.

Joe.

[Amit Zur]

Hi there,
I was curious if this is also available from gcli ? maybe as an argument for `listen` ?

Amit

[Amit Zur]

Oh, sorry, I saw only now that it's controlled by pref devtools.debugger.remote-use-websockets

So I guess if I do `listen 6080` from gcli with the pref on then it uses the websocket server, right?

[Jaroslav Šnajdr]

Hello Amit,

GCLI doesn't support the WebSocket option yet. I filed bug 1295080 to
resolve this issue. It's a nice good first bug, by the way.

The devtools.debugger.remote-websocket pref is consulted only when starting
the debugger server from Firefox command line with
"--start-debugger-server". GCLI "listen 1234" will always use the
non-WebSocket protocol.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1295080

Jarda