Re: How best to architect the InstallTrigger code to support e10s

Dave Townsend wrote:
> As part of the ongoing extension manager rewrite I'm changing a lot of 
> the code that makes the InstallTrigger object available to content JS. 
> As an overview the InstallTrigger object is what websites can use to 
> test whether XPI installation is enabled and to start extension installs.
> 
> The question I have is how to best restructure the code such that when 
> we move to e10s full on the transition is simple. My best guess would be 
> something like this:
> 
> An object that implements InstallTrigger that would run in the content 
> process and talks to an object in the chrome process (initially directly 
> but presumably later through IPDL).

Dave, I don't know what answer you will get, but I'm interested in 
hearing.  Are you implementing InstallTrigger as a "JavaScript global 
property" in XPCOM categories?

It seems to me that InstallTrigger need not be synchronous, nor does it 
need to be part of the chrome process. Ultimately if the user does 
choose install there are some sync points, but you should be able to 
open the dialog with the user, download the XPI, and only when you need 
to restart (or in future trigger the update work) do you need to sync 
with other processes.

If you buy this (and I think this will be common and desirable), then 
your code needs to be compiled in the content process. Some new solution 
is needed to say "Javascript global property content-process" vs 
"Javascript global property application-process".

jjb