Service workers should handle the case when the controlled clients are also Workers.
Catalin, are you talking about exposing them via clients? Because network requests are already intercepted.
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.
Summary: ServiceWorker: Intercept other workers → ServiceWorker: Represent other workers as clients
not working on this for the current sprint (NGA S3) so releasing it for now
Assignee: alberto.crespellperez → nobody
Status: ASSIGNED → NEW
Component: DOM → DOM: Service Workers
Ehsan, this is another compat bug you could possibly work.
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.
Assignee: nobody → ehsan
Seems reasonable. Especially given we need a client ID for bug 1222464.
This depends on my work in bug 1293277.
This was fixed by bug 1293277 and bug 1231211. You now get a FetchEvent.clientId for subresource requests coming from a controlled worker thread.
Status: NEW → RESOLVED
Last Resolved: a year ago
Depends on: 1231211
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.