You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
[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.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
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) andFooObject
(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.The text was updated successfully, but these errors were encountered: