Bugzilla

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:  
```javascript
        // 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;
```
in FrameTransport.jsm

> 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.

Basically I assumed that our isChrome check in FrameTransport.jsm would be consistent with the fact that `includeChrome` is false for our JSWindowActor definition (or rather it's not specified). But since DevTools is using a `<browser type="content">` it probably doesn't get excluded by the JSWindowActor logic. 

So basically 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 the same logic as the one used in FrameTransport.jsm.

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:  
```javascript
        // 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;
```
in FrameTransport.jsm

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.