Upcoming changes to frame scripts
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
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