[editorial] dfn worker's outside/inside port, and clarify event retargeting

[nicolo-ribaudo]

This started as a PR just adding <dfn> to a Worker's outside port, so that the algorithms using it could link to the definition.

However, when reading the definition I then noticed this sentence:

All messages received by that port must immediately be retargeted at the Worker object.

It has two problems:

• there is no definition of what "retargeting an event" means. Actually, DOM does define it, but it's used when it comes to events related to the shadow dom and it would be a no-op on Worker/MessagePort.
• as far as I can tell, not all events from MessagePort are forwarded. Specifically, the close event (which is fired when terminating the worker) is not included in the Worker event handlers table (and there is also an open feature request about it: Event for worker termination #5869). This is correct, because there is no algorithm that can end up triggering a "close" event on that message port, but it could be more explicit. Figuring out that no algorithm can trigger it requires noticing that a "disentangle the ports" step is not linked the "steps to disentangle a port".

So now this PR also explicitly dispatches the message and messageerror events on Worker/DedicatedWorkerGlobalScope rather than "retargeting" them from the MessagePort.

Question about the wording I chose: calling "dispatch an event" is enough to change the event's .target from the MessagePort to the Worker, right?

---

/index.html ( diff )
/web-messaging.html ( diff )
/webappapis.html ( diff )
/workers.html ( diff )

[annevk]

I really like this and I agree it's needed, but I'm afraid it doesn't quite work. E.g., I strongly expect event's "dispatch flag" to still be set at this point. I think we probably have to recreate the event object instead.

[annevk]

At some point this should really be defined to invoke some internal algorithm instead of the public method.

[annevk]

cc @wanderview @asutherland

[nicolo-ribaudo]

E.g., I strongly expect event's "dispatch flag" to still be set at this point.

Yes, it is. However, does it matter? Dispatch an event sets the flag unconditionally as the first step anyway.

[annevk]

Doh, only dispatchEvent() is guarded. But stop propagation and such seems like it would matter? Or maybe even that does not matter as nothing else can get a hold of this event object as the object that does the forwarding is not reachable to script. Hmm.

@smaug---- thoughts?

[nicolo-ribaudo]

I think it does not matter because there is only one listener on that internal object, and the event does not bubble up because we are not in the dom. Capturing/bubbling order is also fine: the internal event listener runs in the "bubbling" phase, but then when dispatching it to the worker it goes again through the capturing and bubbling phases.

[nicolo-ribaudo]

I'll make this better tomorrow

[nicolo-ribaudo]

@annevk I changed this to now store the EventTarget for the message/messageerror events on the MessageChannel itself, so that the MessageChannel can dispatch the events to the right target rather than having this "retargeting" indirection. Wdyt?

[smaug----]

MessageEventTarget concept seems reasonable.

[annevk]

This looks great modulo wrapping concerns. I'm not entirely sure if we should preserve the IDs here. I'd also like at least one other person to review, which likely means we should wait for Domenic to get back next week. Hope that's okay.

This is a very nice incremental improvement to messages though, thanks for working on it!

[nicolo-ribaudo]

No rush, I don't have any concrete need for this patch and it was just a possible improvement I spotted while reading :)

[domenic]

This is amazing.

I do think we should preserve these IDs, as they are linked from MDN and probably elsewhere: https://developer.mozilla.org/en-US/docs/Web/API/MessagePort/message_event#:~:text=%23%20event%2Dmessage-,HTML%20Standard,%23%20handler%2Dmessageport%2Donmessage,-Browser%20compatibility

To do this, just add id="..." in appropriately-nearby places (inserting empty <span>s if necessary).

[nicolo-ribaudo]

@domenic Done, I added them so that old links now go to the MessageEventTarget event handles table.

For MessagePort it would also be possible to make them go to MessagePort's event handlers table (which still contains onclose, and that is followed by a requirement about onmessage), but that table doesn't exist anymore for the other two interfaces.