new code to help with cross-process windows/workers (and Clients API)

[Ben Kelly]

Hi all,

I just want to give you a heads up about some new infrastructure that is
landing in the tree. In particular, we now have:

1. A central list of windows and workers for the entire browser in the
parent process. This includes information on their origin, url, and what
process they are running in. This lives in ClientManagerService.

2. A structure called ClientInfo which lets you refer to a particular
window or worker. This can be passed between threads/processes and then
used to attach to the running window/worker by creating a ClientHandle
object.

3. ClientHandle provides initial support for focusing and navigating
windows. You can also postMessage() both window and worker clients.

4. A ClientManager interface allows you to query the list of clients in the
system and open windows regardless of your current process/thread.

In the future we may move values that apply to both windows and workers to
the new ClientInfo type. For example, we have plans to move CSP from
nsIPrincipal. Other data like referrer-policy would that applies to both
windows/workers would also be a good fit.

Before adding new values to nsIDocument or WorkerPrivate, please consider
if they would fit better in the clients infrastructure layer.

Over time it would be nice to move towards the client types since it will
allow us to write more code that "just works" with windows and workers. We
can start removing the conditional "if nsIDocument do X else if
WorkerPrivate do Y" we have in the tree.

This code has been implemented so far in bug 1293277 and its dependents in
order to support a multi-e10s Clients WebAPI:

https://developer.mozilla.org/en-US/docs/Web/API/Clients

Initially we will be using these new features only in Clients API on
service worker threads, but the design supports using it other contexts as
well. I have a spec issue open to support content windows as well.

If there is a desire to access these features from browser chrome script,
please let me know. I think this should be possible once we have use
cases. While not as powerful as our various xpcom components, it might be
more convenient to use for some cases.

Please let me know if you have any question or if you think you have a
feature that could integrate with the clients infrastructure. While the
initial implementation is limited to Clients API needs, I've tried to
design it to support other internal uses. I'd be very happy to help get
new features added to support browser chrome or native code.

Thanks!

Ben

P.S. I was also thinking of doing a blog post with diagrams of how it works
if people think that would be useful.

[Nicholas Alexander]

Hi Ben,

On Fri, Dec 8, 2017 at 12:23 PM, Ben Kelly <bke...@mozilla.com> wrote:

> Hi all,
>
> I just want to give you a heads up about some new infrastructure that is
> landing in the tree. In particular, we now have:
>


1. A central list of windows and workers for the entire browser in the
> parent process. This includes information on their origin, url, and what
> process they are running in. This lives in ClientManagerService.
>

This is the kind of work that makes me wonder how we _didn't_ have this
central list before :)

<snip>

> P.S. I was also thinking of doing a blog post with diagrams of how it works
> if people think that would be useful.
>

I personally think this would be useful, and will (probably) only happen if
you do it now, before you move on to the next thing. +1 for documentation!

Thanks for this work!
Nick

[Mike Conley]

This all sounds great!

>> I personally think this would be useful, and will (probably) only happen if
>> you do it now, before you move on to the next thing. +1 for documentation!

I concur.

[Ben Kelly]

On Fri, Dec 8, 2017 at 4:38 PM, Mike Conley <mco...@mozilla.com> wrote:

> >> I personally think this would be useful, and will (probably) only
> happen if
> >> you do it now, before you move on to the next thing. +1 for
> documentation!
>
> I concur.
>

Alright. I'll work on a blog post next week. (I'm not going to be in
Austin for the work week.)

Thanks.

Ben

[Gijs Kruitbosch]

On 08/12/2017 20:23, Ben Kelly wrote:
> Please let me know if you have any question or if you think you have a
> feature that could integrate with the clients infrastructure. While the
> initial implementation is limited to Clients API needs, I've tried to
> design it to support other internal uses. I'd be very happy to help get
> new features added to support browser chrome or native code.

Sorry if this was answered by implication somewhere in the OP already (I
looked, but must have missed it!), but is this infrastructure
exposed/available to Chrome JS, and message manager messages (as opposed
to C++-based IPC with ipdl etc.) ?

In particular, in situations where we currently have content scripts
that need to go ask the parent process something, and the parent then
needs to go back to the content process with an answer, without losing
the "reference" to the frame concerned (which may be a subframe, so just
knowing the target browser is not enough), that is currently annoying to
implement (requires e.g. manual window id tracking in the content
process). It sounds like this API might make this type of thing easier
to implement if we could use it from chrome JS.

~ Gijs

[Ben Kelly]

On Dec 9, 2017 8:25 AM, "Gijs Kruitbosch" <gijskru...@gmail.com> wrote:

On 08/12/2017 20:23, Ben Kelly wrote:

> Please let me know if you have any question or if you think you have a
> feature that could integrate with the clients infrastructure. While the
> initial implementation is limited to Clients API needs, I've tried to
> design it to support other internal uses. I'd be very happy to help get
> new features added to support browser chrome or native code.
>

Sorry if this was answered by implication somewhere in the OP already (I
looked, but must have missed it!), but is this infrastructure
exposed/available to Chrome JS, and message manager messages (as opposed to
C++-based IPC with ipdl etc.) ?

Not yet, but I have designed it to support that.

Probably the first step would be to expose the Clients WebAPI to browser
chrome script. We could then add more chrome-only features as use cases
arise.

Can you file a bug in Core:DOM and describe a bit more how you would like
to use it?

I just want to make sure anything we expose fits our browser chrome use
cases well.

In particular, in situations where we currently have content scripts that
need to go ask the parent process something, and the parent then needs to
go back to the content process with an answer, without losing the
"reference" to the frame concerned (which may be a subframe, so just
knowing the target browser is not enough), that is currently annoying to
implement (requires e.g. manual window id tracking in the content process).
It sounds like this API might make this type of thing easier to implement
if we could use it from chrome JS.

The Clients API is all promise based and I expect any future API would be
as well. So hopefully that will make things easier.

Thanks.

Ben