Initial cut at the script module #70
Conversation
index.bs
Outdated
| [=responsible document=]'s [=Document/browsing context=] to |related contexts|. | ||
|
|
||
| Otherwise if the [=Realm/global object=] specified by |settings| is a | ||
| {{WorkerGlobalScope}}, for each |owner| in the [=Realm/global object=]'s [=owner |
There was a problem hiding this comment.
OK, so the "for each" here is how we can end up with multiple members in related contexts, which can happen for shared workers.
However, a shared worker is only created once right, and some browsing context has to be the one that brought it about. Can there in fact be multiple owners at the time a realm is created?
In the case that a browsing context later joins the party with a shared worker, is an event needed to signal that, or do we pretent it was created again?
There was a problem hiding this comment.
I think we could at least have multiple contexts associated with a worker if we are emitting events because we subscribed to the script.realmCreated event for some existing contexts and we're backfilling. The spec doesn't cover that yet but I think it will.
I don't know what CDP does with shared workers; could be interesting to investigate.
There was a problem hiding this comment.
OK so let's not block this PR on investigating that, seems like a fine thing to look at while prototyping an implementation.
jgraham
force-pushed
the
script
branch
2 times, most recently
from
ce41f66
to
ad99209
Compare
This adds a method to get a list of existing realms and an event when a new realm is created. It is anticipated that the module will also be used for further script-related commands such as script execution in the future. Realms are given an id and a type parameter according to the kind of global they contain. The set of paramters is extensible to allow for the possibility of further kinds in the future, but the anticipation is they will be added to the specification, so it's a requirement that unknown kinds are prefixed. The getRealms method allows filtering by context to only get realms related to the active document in that context (i.e. workers with that document in the owner set or the window script for that document). There isn't currently a way to get only nested workers or similar; it's not really clear how useful this is.
Co-authored-by: Brandon Walderman <bwalderman@outlook.com>
Co-authored-by: Philip Jägenstedt <philip@foolip.org>
Co-authored-by: Philip Jägenstedt <philip@foolip.org>
This adds a method to get a list of existing realms and an event when
a new realm is created. It is anticipated that the module will also be
used for further script-related commands such as script execution in
the future.
Realms are given an id and a type parameter according to the kind of
global they contain. The set of paramters is extensible to allow for
the possibility of further kinds in the future, but the anticipation
is they will be added to the specification, so it's a requirement that
unknown kinds are prefixed.
The getRealms method allows filtering by context to only get realms
related to the active document in that context (i.e. workers with that
document in the owner set or the window script for that
document). There isn't currently a way to get only nested workers or
similar; it's not really clear how useful this is.
Preview | Diff