Is the MessagePort's owner concept really necessary? #4340
Labels
Comments
<iframe></iframe>
<script>
self[0].setTimeout(() => alert("hi"), 2000);
self[0].location = "frame.html";
</script>At https://bevel-umbrella.glitch.me/ runs the timer in Firefox, but not Chrome/Safari. Not exactly what I expected. |
domenic
added a commit
that referenced
this issue
Jul 10, 2020
The "owner" of a MessagePort is set a lot, but only *used* for determining what document (if any) should be associated with that MessagePort's tasks. I.e., it ensures that when that document becomes not-fully-active, the tasks are not run. Tests [1] show that the use of incumbent settings object for the owner of MessageChannel-created MessagePorts was incorrect. In fact, the current settings object is used. This allows for a dramatic simplification, as it means that the MessagePort's owner is always equal to its relevant settings object. Thus, we can entirely delete the owner concept, and the associated specialized "create a new MessagePort object" algorithm. This does require tweaking the examples of how the incumbent concept works, now that a simple constructor is no longer available to demonstrate the point. This also modernizes the definition of MessageChannel. Closes #4340. Helps with #1430. [1]: web-platform-tests/wpt#24566
3 tasks
domenic
added a commit
that referenced
this issue
Jul 10, 2020
The "owner" of a MessagePort is set a lot, but only *used* for determining what document (if any) should be associated with that MessagePort's tasks. I.e., it ensures that when that document becomes not-fully-active, the tasks are not run. Tests [1] show that the use of incumbent settings object for the owner of MessageChannel-created MessagePorts was incorrect. In fact, the current settings object is used. This allows for a dramatic simplification, as it means that the MessagePort's owner is always equal to its relevant settings object. Thus, we can entirely delete the owner concept, and the associated specialized "create a new MessagePort object" algorithm. This does require tweaking the examples of how the incumbent concept works, now that a simple constructor is no longer available to demonstrate the point. This also modernizes the definition of MessageChannel. Closes #4340. Helps with #1430. [1]: web-platform-tests/wpt#24566
domenic
added a commit
that referenced
this issue
Jul 13, 2020
The "owner" of a MessagePort is set a lot, but only *used* for determining what document (if any) should be associated with that MessagePort's tasks. I.e., it ensures that when that document becomes not-fully-active, the tasks are not run. Tests [1] show that the use of incumbent settings object for the owner of MessageChannel-created MessagePorts was incorrect. In fact, the current settings object (or relevant settings object of this) is used. This allows for a dramatic simplification, as it means that the MessagePort's owner is always equal to its relevant settings object. Thus, we can entirely delete the owner concept, and the associated specialized "create a new MessagePort object" algorithm. This does require tweaking the examples of how the incumbent concept works, now that a simple constructor is no longer available to demonstrate the point. This also modernizes the definition of MessageChannel. Closes #4340. Helps with #1430. [1]: web-platform-tests/wpt#24566
mfreed7
pushed a commit
to mfreed7/html
that referenced
this issue
Sep 11, 2020
The "owner" of a MessagePort is set a lot, but only *used* for determining what document (if any) should be associated with that MessagePort's tasks. I.e., it ensures that when that document becomes not-fully-active, the tasks are not run. Tests [1] show that the use of incumbent settings object for the owner of MessageChannel-created MessagePorts was incorrect. In fact, the current settings object (or relevant settings object of this) is used. This allows for a dramatic simplification, as it means that the MessagePort's owner is always equal to its relevant settings object. Thus, we can entirely delete the owner concept, and the associated specialized "create a new MessagePort object" algorithm. This does require tweaking the examples of how the incumbent concept works, now that a simple constructor is no longer available to demonstrate the point. This also modernizes the definition of MessageChannel. Closes whatwg#4340. Helps with whatwg#1430. [1]: web-platform-tests/wpt#24566
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It refers to either a Document, or a WorkerGlobalScope (or a WorkletGlobalScope?).
But, I think we could probably just replace it with the MessagePort's relevant global in most cases? Especially if we were able to make them owned by Windows instead of Documents. (Switching that might have implications for the initial about:blank transition, though.)
The text was updated successfully, but these errors were encountered: