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

On 3/8/10 14:14, John J Barton wrote:
> 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?

Yes, mostly the same as it has always been implemented, though I am 
switching to a pure XPCOM component rather than using a JS helper object 
as the current implementation does.

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

It certainly doesn't need to besynchronous, but making it fully 
asynchronous would mean changing the API that websites have been using 
since back in the Netscape days (the last time we did this, even for 
bits that were no longer doing anything, we still saw complaints).

I'm pretty sure that the bits of InstallTrigger that actually check 
whether software installation is enabled does need to be in the chrome 
process, unless the content processes have access to the preferences and 
permission manager. Obviously the part that actually starts extension 
downloads and installs needs to run in the chrome process.

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

I'm not really sure what you've proposed. It's pretty much a given that 
there has to be a part of this running in the content process and a part 
in the chrome process I think.