Closed Bug 1605584 Opened 1 year ago Closed 1 year ago

Support connecting to remote replaying processes


(Core Graveyard :: Web Replay, enhancement)

Not set


(firefox73 fixed)

Tracking Status
firefox73 --- fixed


(Reporter: bhackett1024, Assigned: bhackett1024)


(Blocks 1 open bug)



(1 file, 2 obsolete files)

Right now, middleman processes can only connect to replaying processes which were spawned on the local machine by their own ContentParent. In order to use replaying processes in the cloud, we need to be able to connect to remote processes over a network connection. The attached patch does this; it works and is pretty much done, but I'm going to hold off on reviews until cloud support is further along.

Because communication with a replaying process is done using a single duplex channel, this is pretty straightforward to implement. We create that channel as normal in the middleman, but instead of placing the other channel endpoint in a local replaying process, we place the endpoint in the parent process, and wire it up to some JS that creates a WebSocket for communicating with the remote server (specified as a preference for now). The JS forwards data in both directions between the channel with the middleman and the socket with the remote process. So far I've tested this with a simple echoing websocket server, and the next step will be to use a websocket server that can create its own replaying processes.

There is some trickiness here in terms of where the JS owning the websocket is located. This patch puts the JS in the parent process; it would be nicer to put the JS in the middleman process since each websocket will be associated with a specific middleman. Using the middleman doesn't work, however, because we need to be able to synchronously communicate over the channel without spinning the main thread's event loop (this is needed to preserve run-to-completion semantics when calling debugger methods that require communicating with a replaying process), and using a websocket in a content process involves main thread runnables, even when the socket is owned by a worker thread (all the websocket communication happens in the parent process anyways, and happens via IPDL messages that must be sent/received on the content process' main thread). In any case, given these constraints I think that what this patch is doing is the most appropriate approach.

Attached file WIP (obsolete) —
Attached patch WIP (obsolete) — Splinter Review

This patch fixes a number of issues with connecting to remote replaying processes, as well as getting replaying macOS recordings on linux to work more reliably. With this patch and the current state of the ReplayLinker repository (, I can use web replay on a simple page, connect to a remote replaying process on an AWS instance, and core functionality like scanning the recording, seeking to breakpoint hits in the past, and updating the UI/gfx all work. Web replay is in the cloud!

Attachment #9117433 - Attachment is obsolete: true
Attachment #9118174 - Attachment description: Bug 1605584 Part 1 - Create replaying processes in the cloud when requested, r=mccr8. → Bug 1605584 - Create replaying processes in the cloud when requested, r=mccr8.
Depends on: 1606447
Attachment #9117738 - Attachment is obsolete: true
Pushed by
Create replaying processes in the cloud when requested, r=mccr8.
Pushed by
Create replaying processes in the cloud when requested, r=mccr8.
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla73
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.