Upcoming changes to frame scripts

Kris Maglione kmaglione at mozilla.com
Mon Aug 13 19:42:36 UTC 2018

On Mon, Aug 13, 2018 at 04:24:42PM +0100, Andreas Tolfsen wrote:
>The goals stated here are laudable and I’m sure these changes are 
>for the better, but I’m scared of the cost involved in rewriting 
>large and complicated pieces of frame scripts will have on downstream 

Which downstream consumers?

>It seems like the focus of Fission so far has been to convert 
>stateless pieces of the Firefox frontend code to this ‘actor model’ 
>you mention.  Where do we find documentation about this model?

At the moment, in ActorManagerParent.jsm, although note that 
this will change as we introduce JS IPDL and Fission actors:


>Can the ActorChild be used in conjunction with a regular frame 
>script model?

To some extent, yes. Although the plan is to phase out regular 
frame scripts. I'm hoping to get rid of all non-test frame and 
process scripts within the next few weeks.

>The Marionette frame script (testing/marionette/listener.js) is 
>rather large, complicated, and maintains a lot of state.  How can 
>you work with state across process-scoped and (presumably) isolated 

Separate actor instances are created for each child message 
manager, though they're loaded into the same scope.

>One of the advantages of frame scripts is that they have a narrower 
>global scope than the child process JSMs do.

This is to a large extent untrue, and to a large extent a 

Each JSM has its own scope, and while all JSMs are technically 
loaded into the same global, they have limited ability to modify 
that global. And, while most frame scripts are loaded into their 
own scope, they all share the same `this` object, which is 
currently the top-level message manager global. That makes it 
very easy for one script to pollute the environments of other 
scripts (and often leads to one frame script relying on the 
side-effect of another).

It also requires that we clone and re-execute each top-level 
frame script for each child message manager we create, which is 
extremely expensive, both in terms of memory and in terms of 

More information about the firefox-dev mailing list