Closed Bug 1605584 Opened 1 year ago Closed 1 year ago

Support connecting to remote replaying processes

Categories

(Core Graveyard :: Web Replay, enhancement)

enhancement
Not set
normal

Tracking

(firefox73 fixed)

RESOLVED FIXED
mozilla73
Tracking Status
firefox73 --- fixed

People

(Reporter: bhackett1024, Assigned: bhackett1024)

References

(Blocks 1 open bug)

Details

Attachments

(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 (https://github.com/bhackett1024/ReplayLinker), 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 bhackett@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/af6e8b6be574
Create replaying processes in the cloud when requested, r=mccr8.
Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c7701962744c
Create replaying processes in the cloud when requested, r=mccr8.
Status: NEW → RESOLVED
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.