Fire the "close" event on MessagePort from a task - #12957
nicolo-ribaudo wants to merge 2 commits into
Conversation
|
|
||
| <li><p><span data-x="concept-event-fire">Fire an event</span> named <code | ||
| data-x="event-close">close</code> at <var>otherPort</var>.</p></li> | ||
| <li><p><span>Queue a global task</span> on the <span>DOM manipulation task source</span> given |
There was a problem hiding this comment.
MessagePorts have a port message queue task source, but using that same task source would be a larger normative change since we'd start requiring that the close event is only fired after that all messages have been processed.
There was a problem hiding this comment.
I think we should use the port message queue task source, and therefore also amending the transfer-receiving steps to explicitly mention "close" events in addition to "message" events when it "Move(s) all the tasks...".
This is because we can transfer a MessagePort that still has several messages in its queue and that has been closed by the other side, and it makes sense for all of those messages and then the close event to be fired wherever that MessagePort ends up and that will be very content-observable (versus the messages transferring but the close event firing on the otherwise dead MessagePort in the transferring global). So I think it's really the only way we can sanely specify it. Hand-wavingly, I think the case can be made that the ambiguity of the current under-specification might imply this, but it's also incredibly ambiguous, so thank you for undertaking this cleanup!
There was a problem hiding this comment.
I should also note that while I can only speak from a Gecko perspective, both our current implementation of MessagePorts that used a centralized router model and our/my planned overhaul of MessagePorts that uses direct endpoint connections both favor use of the port message queue task source and re-shipping. I think it would be a somewhat weird IPC model where it would be easier for an implementation to do the global task that wasn't effectively using the port message queue up until the last second.
foolip
added
the
needs implementer interest
|
I added the "needs implementer interest" label because I expect that will block landing this PR. Or is there implementer interest from @asutherland? |
|
Fwiw if there is no implementer interest for this PR because nobody ships this event, I'd also be happy to open a PR just removing it. |
|
IMO we can view this PR as a bug fix that doesn't affect current implementations. But there should be bugs filed about supporting the |
|
We should just remove this event from the specification until we have a design we are satisfied with. I raised this in 2024 #1766 (comment) and nobody resolved the new issue so I'm not sure why we keep pretending this is good. |
|
If no implementation has shipped the closed event I think it makes sense to first remove it and then open a new PR as if it was new. This way it's easier to review it for what it is, not as a delta against something that was never implemented. |
|
OK, fair enough. |
This is a revert of cc2634f (it's not a "clean" revert because of some other changes that happened in the meantime). This mans that this patch also restores the older GC semantics: a port is not easily GC-able, it is not exlicitly disentangled when the other half's owner document is destroyed, and relies on polling to see if the other half is still alive. I believe this matches Firefox's behavior, which is also what I believe the discussion in whatwg#10201 leads to. Note that browsers have all different GC semantics (according to Claude): - Chromium makes a port uncollectable only if it's already started - Firefox does not collect them - WebKit keeps the port uncollectable only if it has a message listener Given that no browser ships the `close` events this revert is probably the best thing to do; if somebody in the future wants to reintroduce it some relevant discussions are: - whatwg#1766 - whatwg#9933 - whatwg#10201 - whatwg#12797 - whatwg#12957
This is a revert of cc2634f (it's not a "clean" revert because of some other changes that happened in the meantime). This mans that this patch also restores the older GC semantics: a port is not easily GC-able, it is not exlicitly disentangled when the other half's owner document is destroyed, and relies on polling to see if the other half is still alive. I believe this matches Firefox's behavior, which is also what I believe the discussion in whatwg#10201 leads to. Note that browsers have all different GC semantics (according to Claude): - Chromium makes a port uncollectable only if it's already started - Firefox does not collect them - WebKit keeps the port uncollectable only if it has a message listener Given that no browser ships the `close` events this revert is probably the best thing to do; if somebody in the future wants to reintroduce it some relevant discussions are: - whatwg#1766 - whatwg#9933 - whatwg#10201 - whatwg#12797 - whatwg#12957
This is a revert of cc2634f (it's not a "clean" revert because of some other changes that happened in the meantime). This means that this patch also restores the older GC semantics: a port is not easily GC-able, it is not explicitly disentangled when the other half's owner document is destroyed, and relies on polling to see if the other half is still alive. I believe this matches Firefox's behavior, which is also what I believe the discussion in whatwg#10201 leads to. Note that browsers have all different GC semantics (according to Claude): - Chromium makes a port uncollectable only if it's already started - Firefox does not collect them - WebKit keeps the port uncollectable only if it has a message listener Given that no browser ships the `close` events this revert is probably the best thing to do; if somebody in the future wants to reintroduce it some relevant discussions are: - whatwg#1766 - whatwg#9933 - whatwg#10201 - whatwg#12797 - whatwg#12957
This is a revert of cc2634f (it's not a "clean" revert because of some other changes that happened in the meantime). This means that this patch also restores the older GC semantics: a port is not easily GC-able, it is not explicitly disentangled when the other half's owner document is destroyed, and relies on polling to see if the other half is still alive. I believe this matches Firefox's behavior, which is also what I believe the discussion in whatwg#10201 leads to. Note that browsers have all different GC semantics (according to Claude): - Chromium makes a port uncollectable only if it's already started - Firefox does not collect them - WebKit keeps the port uncollectable only if it has a message listener Given that no browser ships the `close` events this revert is probably the best thing to do; if somebody in the future wants to reintroduce it some relevant discussions are: - whatwg#1766 - whatwg#9933 - whatwg#10201 - whatwg#12797 - whatwg#12957
|
Closing this per comments above. |
This is a revert of cc2634f (it's not a "clean" revert because of some other changes that happened in the meantime). This means that this patch also restores the older GC semantics: a port is not easily GC-able, it is not explicitly disentangled when the other half's owner document is destroyed, and relies on polling to see if the other half is still alive. I believe this matches Firefox's behavior, which is also what I believe the discussion in whatwg#10201 leads to. Note that browsers have all different GC semantics (according to Claude): - Chromium makes a port uncollectable only if it's already started - Firefox does not collect them - WebKit keeps the port uncollectable only if it has a message listener Given that no browser ships the `close` events this revert is probably the best thing to do; if somebody in the future wants to reintroduce it some relevant discussions are: - whatwg#1766 - whatwg#9933 - whatwg#10201 - whatwg#12797 - whatwg#12957
This is a revert of cc2634f (it's not a "clean" revert because of some other changes that happened in the meantime). This means that this patch also restores the older GC semantics: a port is not easily GC-able, it is not explicitly disentangled when the other half's owner document is destroyed, and relies on polling to see if the other half is still alive. I believe this matches Firefox's behavior, which is also what I believe the discussion in #10201 leads to. Note that browsers have all different GC semantics (according to Claude): - Chromium makes a port uncollectable only if it's already started - Firefox does not collect them - WebKit keeps the port uncollectable only if it has a message listener Given that no browser ships the `close` events this revert is probably the best thing to do; if somebody in the future wants to reintroduce it some relevant discussions are: - #1766 - #9933 - #10201 - #12797 - #12957 Tests: web-platform-tests/wpt#63174 Closes #10201 and closes #12797.
5 participants
This PR fixes #12797.
Nobody implements
MessagePort'scloseevent (see e.g. #10201) so arguably this PR isn't very useful, but currently the spec is in an invalid state where it fires an event without having a clear JS context running.This patch moves the event to be fired from a task scheduled on the target's message queue, so that:
Corresponding HTML AAM & ARIA in HTML issues & PRs:MDN issue is filed: …(See WHATWG Working Mode: Changes for more details.)
/web-messaging.html ( diff )