Skip to content
This repository was archived by the owner on Aug 13, 2018. It is now read-only.

Analyses (internal architecture)

Jump to bottom
Jan Odvarko edited this page Apr 20, 2016 · 1 revision

This page serves as a central place for collecting information about required WebSocket platform API.

Requirements

  • Get list of existing WS connections (we need to filter per tab)
  • Track opening and closing of WS connections (we need to filter per tab)
  • Intercept all sent/received frames for specific connection
  • Access full frame data (both frame meta data as well as the payload)

User stories: https://etherpad.mozilla.org/Websocket

Bugzilla

List of existing bugzilla reports

  • Jeff: (meta) Bug 885508 - Allow developers to inspect websocket connections
    • Patch monkey patching WebSocket JS API availble, but it's dead end, platform API needed
    • Comment #28, great WS background introduction
  • Jeff: Bug 927481 - observe in-content WebSocket frames
    • Request to observer WS frames. Observing messages doesn't seem to be enough (a message can span more frames).
    • But Comment #6 from bug 885508 done later says that observing messages could be actually enough.
  • Nick: Bug 977858 - Should be able to attach an nsiWebSocketListener to a web socket that's already open
    • Suggested API: .SetObserver(nsIWebsocketListener, nsIEventTarget);
    • Comment #3 suggests that only a single observer will be supported. No way, there can be more extensions observing the WS connections.
  • Bug 720176 - WebConsole should be able to log WebSocket messages
  • Bug 765651 - WebSocket connections are listed with the "http:" protocol in the console.
  • Jim: Bug 1103189 - WebSockets should allow developer tools code to observe socket activity
    • This is very much like bug 977858, although that suggests a very different approach.
    • Mentored by Jim, but doesn't seem to be finished
  • Jim: Bug 1103257 - The Firefox Devtools need a WebSockets inspector panel
    • Suggesting a new WS panel, but original idea was to put WS into Network panel, but a comment in bug 885508 says that Network panel isn't suitable.
  • Jim: Bug 1103263 - The DevTools needs WebSocket Manager and Inspector actors.
    • Suggested new RDP protocol packet types (the architecture: Panel <--> Actors <--> Web Socket Objects)
  • Axel: Bug 1197900 - Protocol handlers for protocol upgraded websocket connections
    • It should be possible to register specific protocol parsers (e.g. socket.io)
    • All protocol identifiers are necessarily registered with iana registration for websocket protocols.
  • Axel: Bug 1197903 - Protocol independent payload parsing of websocket traffic
    • Basic JSON parser should be built-in
  • Axel: Bug 1203827 WS Connections per tab Discovery API for Devtools
  • Axel: Bug 1203308 US: websocket connections discovery across a tab
  • Axel: Bug 1197900 Protocol parsers for protocol upgraded websocket connections
  • Bug 1103189 WebSockets should allow developer tools code to observe socket activity
  • Andrea Bug 1215092 - WebSocketFrameService should be used for WebSocket discovering

Articles

Further Resources

Collection of helpful features already used in the DevTools and what is missing

how to detect new websocket connections?

a debugger server client can subscribe on the webconsole actor the following RDP events: "networkEvent", "networkEventUpdate" (already used in the network monitor)

We can already receive notification of the opened http request and recognize which ones are upgrades into websockets:

{
  "from": "server1.conn5.child1/netEvent27",
  "type": "networkEventUpdate",
  "updateType": "responseStart",
  "response": {
    "httpVersion": "HTTP/1.1",
    "remoteAddress": "174.129.224.73",
    "remotePort": 443,
    "status": "101",
    "statusText": "Web Socket Protocol Handshake",
    "headersSize": 423,
    "discardResponseBody": true
  }
}

We can recognize the websocket protocol, extension and other info by requesting the connection headers like the network monitor already does:

request:

{
	"to": "server1.conn5.child1/netEvent27",
  "type": "getResponseHeaders"
}

reply:

{
  "from": "server1.conn5.child1/netEvent27",
  "headers": [ { "name": "...", "value": "..." }, ... ],
  "headersSize": 423,
  "rawHeaders": "HTTP/1.1 101 Web Socket Protocol..."
}

How to get the WebSocket instances from the inspected tab

We can get the existent WebSocket objects in the page using the same feature used by webaudio or promise actors (and we can probably be notified from the debugger when a new WebSocket instance is created):

let dbg = this.parentActor.makeDebugger();
dbg.addDebuggees();
let obj = dbg.findObjects({class: "WebSocket" })[0];
obj.unsafeDereference(); // returns the original websocket object

To monitor the exchanged messages with the same approach used in the WebAudio and WebGL devtools, we can probably use the CallWatcherActor to monitor the messages sent using the WebSocket "send" method, and register a listener to the DOM WebSocket object to monitor the messages received (and detect when the connection is closed).

What cannot be done and we probably want to

how to retrieve the WebSocket instance related to the connection received in networkEvent/networkEventUpdate events?

  • how to correlate the object received by the network monitoring feature (which should be an object with the nsIChannel if I'm not wrong) and the WebSocket object which generated the request?

  • in alternative to the CallWatchActor, how about an interface, available only to the privileged code, which helps us to install our instrumentation event handlers (something like ws.QueryInterface(Ci.nsIWebSocketDevtoolMonitor)?)

WebRTC

  • (meta) Bug 1210127 - (WebRTC-Tooling) WebRTC Monitoring
  • Bug 1210147 - Inspect WebRTC Data Channels (@Transport level) in a tab
  • Bug 1210160 - webRTC Data Channel Protocol Listener API for devtools webRTC inspector
Clone this wiki locally