ServiceWorker: Represent other workers as clients

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
5 years ago
a year ago

People

(Reporter: catalinb, Assigned: bkelly)

Tracking

(Blocks 2 bugs)

Trunk
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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.
Flags: needinfo?(catalin.badea392)
(Reporter)

Comment 2

4 years ago
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.
Flags: needinfo?(catalin.badea392)

Updated

4 years ago
Summary: ServiceWorker: Intercept other workers → ServiceWorker: Represent other workers as clients
Blocks: 1130687
No longer blocks: 1130687
Blocks: 1130685

Updated

4 years ago
Assignee: nobody → alberto.crespellperez
Status: NEW → ASSIGNED
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
Depends on: 1221772
Ehsan, this is another compat bug you could possibly work.
Flags: needinfo?(ehsan)

Comment 5

3 years ago
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
Flags: needinfo?(ehsan)
Seems reasonable.  Especially given we need a client ID for bug 1222464.
(Assignee)

Updated

3 years ago
Blocks: 1206947
(Assignee)

Updated

2 years ago
Blocks: 1221772
No longer depends on: 1221772
This depends on my work in bug 1293277.
Assignee: ehsan → bkelly
No longer blocks: ServiceWorkers-postv1
Depends on: 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.