An important thing here is that we use different codepaths to create the actor if you open the toolbox before subscribing or after.
When I tried your scenario yesterday, I was opening the toolbox before, and didn't get any message handler created for DevTools. This is because we explicitly exclude chrome contexts & parent process contexts for broadcast via:
// Skip window globals running in the parent process, unless we want to
// support debugging Chrome context, see Bug 1713440.
const isChrome = browsingContext.currentWindowGlobal.osPid === -1;
But when we open DevTools after subscribing to log.entryAdded, then we rely on the JSWindowActor to create the MessageHandler. Before we create the MessageHandler, there must have been a DOMWindowCreated event which fits the JSWindowActor definition, and there must be a session data item with a context which matches this new window global. Since all our session data items are for "ALL" at the moment, it means the only "filter" in effect here will be the JSWindowActor definition.
I assumed that our
isChrome check in FrameTransport.jsm would be consistent with the
includeChrome = false in the JSWindowActor definition (or rather it's lack of value). But since DevTools is using a
<browser type="content"> it probably doesn't get excluded by the JSWindowActor logic.
So our issue here is that some chrome contexts are not filtered out as expected, and we'll need to make sure we have a consistent filtering between our broadcast codepath and the sessiondata (which relies on JSWindowActor events) codepath.
In my opinion the way forward is to make the JSWindowActor definition broader (includeChrome true, allFrames true, etc.) and filter with similar logic as the one used in FrameTransport.jsm. Right now the logic to compare the current context to the session data items context descriptor is in
_isRelevantContext in WindowGlobalMessageHandler. But we might move this filtering earlier, before we create the MessageHandler, and filter on chrome/parent-process contexts here.
Or we could check with platform if they could exclude DevTools browsing contexts when
includeChrome is false? (given that devtools uses type=content, I guess it might be difficult, but maybe worth asking).
As it looks like the DevTools toolbox creates a wrapper around our actor which causes an instance to be created.
I think it's rather that
this._browserContainer.appendChild(this.frame); triggers the
DOMWindowCreated event for the toolbox browser and therefore leads to create the actor.
Checking this.manager.isProcessRoot I can temporarily ignore the registration of the message handlers and keep the actor inactive.
We probably shouldn't do that. isProcessRoot can also match content frames, I think it describes that a given browsing context is the topmost for its process.