Skip to content

SharedWorker constructor presumes sync access to several global objects while in parallel #11314

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ADKaster opened this issue May 16, 2025 · 0 comments
Labels
clarification Standard could be clearer topic: workers

Comments

@ADKaster
Copy link
Contributor

ADKaster commented May 16, 2025

What is the issue with the HTML Standard?

The SharedWorker constructor step 11 queues a job on a parallel queue to do the task of 1) choosing an existing shared worker to connect to or 2) create a new shared worker to connect to, if there isn't a suitable existing SharedWorkerGlobalScope owned by the user agent.

First, step 11 tries to iterate over "For each scope in the list of all SharedWorkerGlobalScope objects:". If this spec step is taken literally, it would imply that all SharedWorkerGlobalScope objects and all owners of a SharedWorkerGlobalScope all live in the same agent cluster. No browser implements their process model like this. The ServiceWorker spec does a slightly better job of explaining that user agents are expected to have some global user agent state (possibly in their UI process, but perhaps not) that tracks metadata about all live ServiceWorkerGlobalScope objects, their agents, and the agent clusters for those agents. [1].

The way this iteration is written hides the reality that implementations are likely forced to queue this request to some centralized place, and perform several hops of IPC to get this registration done.

Step 11.4 fails to specify that we should be firing the error event in the general direction of outside settings.

Step 11.5 then attempts to perform steps on the chosen SharedWorkerGlobalScope. But there is no consideration for the fact that the SharedWorkerGlobalScope is going to be in a worker agent, not the (possibly) similar-origin window agent for the caller of new SharedWorker(). The caller could be a dedicated worker or another shared worker, but even still. Agents. The step should probably say something like, "run the following steps in the relevant agent for worker global scope"

Step 11.6 at least calls an algorithm that has been updated for proper agent considerations. run a worker will explicitly choose a worker agent to execute the final steps in.

Somewhat related to:

#5362 (comment)
#5323 (comment)

[1] I personally dislike how the ServiceWorker spec talks about foo object (the user agent data structure) and FooObject (the WebIDL interface object exposed to either the service worker owner or the service worker global scope, but never both). The similarity between those names is very confusing to implement from.

@annevk annevk added clarification Standard could be clearer topic: workers labels May 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Standard could be clearer topic: workers
Development

No branches or pull requests

2 participants