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

On 3/8/10 15:06, John J Barton wrote:
> Dave Townsend wrote:
>> On 3/8/10 14:14, John J Barton wrote:
>>> Dave Townsend wrote:
>>> 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).
>
> Sorry I think I used the words wrong. The InstallTrigger call from the
> page should block the page. But InstallTrigger does not need to lock the
> chrome process or run there.
>
>>
>> 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.
>
> Read access to preferences/permissions should be available without
> blocking in the content process while this data is analyzed.

I've double checked and preferences are available in content (though we 
shouldn't rely on them remaining so) but the permissions manager isn't, 
and we need that in order to test whether extension installation is 
allowed by a given website so we must perform that work in the chrome 
process, blocking the content process as we do it.

> The download can be done with code in the content process; the only time
> you need to sync with the chrome process is the actual install.

Add-on downloads and installs from all webpages need to be handled in 
the chrome process so that the UI can be centralized. What reason is 
there for trying to do this in the content 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.
>
> Application-level in-memory data needs to be managed in the chrome
> process. But you don't have to run code that analyzes this data in the
> chrome process. The content process can get a copy. Think of the the
> chrome process as an http-ish server and the content process as http-ish
> clients. We know that architecture ;-). Your code GETs the permissions,
> and GETs the preferences and loads the XPI then only after doing all of
> this work independent of the chrome process does it POST the extension
> update. (I don't mean literally GET, that would be done at a lower
> level, but as a developer you would understand the data synchronization
> model as GET/POST).

Unfortunately synchronous access to the preferences and permissions 
manager is required for the current InstallTrigger API. I think it would 
be pretty inefficient for the content process to get a copy of the 
preferences and permissions each time InstallTrigger.updateEnabled() 
were called, much simpler to just pass that question off to the chrome 
process directly I think.