How I want to structure the implementation of my Bachelor Thesis project.

Target Audience

The target audience for this article is people already familiar with the Firefox codebase that are advising with the implementation of my Bachelors Thesis project.

Summary

I want to build a system that allows to monitor calls from WebAPIs. For more details please see my original post.

The currently planned system:

The current state of the implementation can be found here

Details

High-Level

I want to implement a WebExtensionAPI (browser.callMonitor) that allows users to register for events, have their callback invoked once any of the events they registered for happened and then allow them to unregister their callbacks. For that to happen I implement the following:

1. The WebExtension API
2. An API the WebAPI implementations can submit events to
3. The plumbing to connect both of these together

As for the plumbing I envision an IPC actor pair for each content window and having the actor parent managed by CallMonitorManager.

CallMonitorManager

This class is the primary entry point for all CallManager related activities. It implements the nsICallMonitorSubscriptionManager which is how privileged code (e.g. a WebExtensionAPI implementation) can interact with the project. It receives both the callback and the config, generates a unique ID for each registration and forwards the config to each registered CallMonitorParent.

To receive the events that happened in the content processes it provides an EventHappened method that is the same as the RecvEventHappened implemented on CallMonitorParent so each actor parent can forward their events to the CallMonitorManager singleton.

PCallMonitor

As per this currently WIP bit of documentation using PContent as a dump protocol is not an antipattern for actors that use very short operations that have no synchronization needs which I would consider my protocol to be, so PCallMonitor is managed by PContent.

CallMonitorParent

CallMonitorParent is one half of the actor pair that I use to pass config from the parent process to the content process and to pass the recorded events back from the content process to the parent process.

It registers itself on creation with the CallMonitorManager, to receive all currently active configs and to be notified of any changes.

CallMonitorChild

The CallMonitorChild is the only part of the CallMonitor architecture that exists in the content process. It holds all active configs and their ids so it is able to:

1. Check if an event should be submitted

2. Figure out whether the call stack or the function arguments should be submitted as well

   2.1. If the call stack should be submitted, capture the call stack.

3. Create a CallMonitorEvent and send that over to the CallMonitorParent along with a list of ids for which this event is relevant

This happens every time an WebAPI that has been integrated gets called so step 1 should be as fast as possible to reduce runtime impact.

Open Problems

Capturing call stack

How would I go about capturing the current JS call stack while in C++?

Protocol

All IPDL documentation says, that it’s much better to implement a sub protocol than to worry about getting the actors set up on your own. However, I don’t know which protocol to integrate with.

WebExtensionAPI

What code could I use as reference for this? I don’t know how passing information from the WebExtension Process to the Parent Process works.