1032521 - ServiceWorker: Represent other workers as clients

Status: RESOLVED FIXED

(Core :: DOM: Service Workers, defect)

Description

[Cătălin Badea (:catalinb)]

Service workers should handle the case when the controlled clients are also Workers.

Comment 1

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

Catalin, are you talking about exposing them via clients? Because network requests are already intercepted.

Comment 2

[Cătălin Badea (:catalinb)]

This more of a default TODO reference used whenever worker clients were involved. I guess now it should track exposing workers as clients and getting postMessaging to work.

Comment 3

[Noemí Freire (:noemi)]

not working on this for the current sprint (NGA S3) so releasing it for now

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

Ehsan, this is another compat bug you could possibly work.

Comment 5

[(no longer active)]

In some places we would need to enumerate all clients (such as Clients.getAll()) and because of nested dedicated workers, maintaining a list of all WorkerPrivates that currently exist is problematic because the WorkerPrivate for nested workers can't be accessed on the main thread.  Here is my plan for this:

* Give each worker private an immutable clientId.  The clientId will be accessible both on the worker thread and the parent thread as it's immutable.
* When enumerating the list of clients, use the runtime service to find workers associated with a window.  That gives us shared workers and top-level dedicated workers.
* Iterate over mChildWorkers and post messages to the nested workers as needed.
* Since the clientId for mChildWorkers can be read from the parent thread, we'd be able to find the clientId we're looking for always on the main thread.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

Seems reasonable.  Especially given we need a client ID for bug 1222464.

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

This depends on my work in bug 1293277.

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

This was fixed by bug 1293277 and bug 1231211.  You now get a FetchEvent.clientId for subresource requests coming from a controlled worker thread.