1207778 - Add support for multiple content processes to SharedWorker

Status: RESOLVED DUPLICATE of bug 1438945

(Core :: DOM: Service Workers, defect, P2)

Description

[(no longer active)]

Currently if two pages from the same scope run in two different content processes, they will get their own copy of the service worker.  This is incorrect, we need to run only one copy in only one process.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

This can only happen on b2g when an embedded iframe is opened, right?  I thought top level apps/pages always shared the same process with other app/pages of the same origin.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

(In reply to Ben Kelly [:bkelly] from comment #1)
> This can only happen on b2g when an embedded iframe is opened, right?  I
> thought top level apps/pages always shared the same process with other
> app/pages of the same origin.

Fabrice, is this correct?

Comment 3

[(no longer active)]

This can happen on b2g in the browser app since we run each page in its own process.

It will also be an issue on desktop when e10s moves to multiple content processes.  But this is currently a more immediate need to support b2g.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

Should we consider the architecture where we have a separate service worker process again?  Or are we going to try to peer-to-peer normal content processes?  That sounds like a huge set of bugs waiting to happen.

I think this same issue applies to SharedWorker, so we might as well fix that while we're at it.

Comment 5

[(no longer active)]

(In reply to Ben Kelly [:bkelly] from comment #4)
> Should we consider the architecture where we have a separate service worker
> process again?  Or are we going to try to peer-to-peer normal content
> processes?  That sounds like a huge set of bugs waiting to happen.

There is trade-offs.  There is no support currently for running a content process just for a service worker AFAIK.  There is support for running tabs in content processes obviously but I don't know if that model still works if all of the tabs are unloaded and the process is left with a service worker.  "P2P"ing content processes is easier if creating SW only processes is hard and if the issue of the process being left around without a tab and just a SW is easily fixable.  If we choose to run SWs in their own processes always, then we're going to have to talk about the overhead of doing so for the common case where the SW and the page both run in the same process (aka only one tab open to the website).  I don't know if having that overhead is acceptable.

In summary, this needs quite a bit of investigation and planning.

> I think this same issue applies to SharedWorker, so we might as well fix
> that while we're at it.

Oh yes, of course.  SWs are just shared workers ultimately so we need to fix this at the shared worker level.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

This might be easier to solve for ServiceWorker than SharedWorker.

Once we move the SWM to the parent process, it can keep track of which content process each SW is running in.  It can than send back messages referring new attachments to the existing content process.  Straightforward, modulo a ton of race conditions and details.

We would have to create some central thing to solve the SharedWorker case.

Comment 7

[(no longer active)]

(In reply to Ben Kelly [:bkelly] from comment #6)
> We would have to create some central thing to solve the SharedWorker case.

Yeah, it may be worth doing this to avoid fixing this once for shared and once for service workers...

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

We have a separate effort for service worker in multiple content processes.  I'm changing this bug to just SharedWorker.  We should do this after ServiceWorker multi-e10s.

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

Andrea has started working on this in bug 1438945.