Implemented here: https://searchfox.org/mozilla-central/rev/b2b0077c2e6a516a76bf8077d6f0237c58f5959a/browser/actors/LightweightThemeChild.jsm
Registered here: https://searchfox.org/mozilla-central/rev/b2b0077c2e6a516a76bf8077d6f0237c58f5959a/browser/components/BrowserGlue.jsm#317-325
Interestingly, this actor doesn't actually do any cross-process communication directly. It's job is to attach itself to about:home, about:newtab and about:welcome, and check the
Services.cpmm.sharedData structure for any theme data to apply, and then sends a special event down to content to apply that data.
There are two other things to note:
- Sidebars use this actor as well, but do so in a really strange way - the sidebars for Sync'd Tabs, History and Bookmarks manually instantiate the LightweightThemeChild actor and mock out a dispatcher rather than relying on the underlying ActorManagerChild thing to do it for them. I guess this is because there's no ActorManagerChild for these sidebars, since those sidebars actually run in the parent process. I suspect we can probably add the bookmarks and history URIs to the matches: registration for the JSWindowActor implementation, and set the
includeChrome property to true in the registration as well, and I think then we can have LightweightThemeChild be instantiated in the "normal" lazy fashion like with about:* pages, instead of manually doing it like we do here.
For reference, the URIs for the sync'd tabs, history and bookmark sidebar pages are:
Services.cpmm.sharedData is keyed on a special identifier,
chromeOuterWindowID, that represents which window a particular Actor is within. This is because each browser window can be themed differently. I suspect until we figure out a way of making
chromeOuterWindowID available on a
BrowsingContext, we should keep getting it off of the message manager. So for now, in the port, let's access the message manager's
chromeOuterWindowID like so: