How best to architect the InstallTrigger code to support e10s

[Dave Townsend]

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). From what I understand it is
allowable for calls from the content process to the chrome process to be
synchronous and block content, but not vice versa?

Is this along the right lines?

Dave

[John J Barton]

Post by Dave Townsend
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
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

[Dave Townsend]

Post by John J Barton
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?

Post by John J Barton
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.

[Dave Townsend]

Post by John J Barton

Post by Dave Townsend
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
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.

Post by John J Barton
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.

Post by John J Barton
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.

[John J Barton]

Post by Dave Townsend

Post by John J Barton

Post by Dave Townsend
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
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.

Post by John J Barton
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.

Post by Dave Townsend
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.

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.

Post by Dave Townsend

Post by John J Barton
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).

jjb

[Benjamin Smedberg]

Post by Dave Townsend
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
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). From what I understand it is
allowable for calls from the content process to the chrome process to be
synchronous and block content, but not vice versa?

Yes. The goal would be to keep as little state in the content process as
possible, I think: what information does the content caller get back from
these APIs? It is a single boolean "started" or "not started" value? If so,
we can probably just make the message a synchronous StartInstall message
returning a single boolean value.

--BDS