postMessage from a remote window is unnecessarily delayed

[jdm]

When a postMessage occurs between two windows that are not similar origin to each other, the source window relays the message via the constellation. When this message is received by the target script thread, it enqueues a task to perform the postMessage receiving steps (ie. dispatch the JS event). This is an unnecessary delay; it would be acceptable from a specification point of view to dispatch the event directly when the script thread receives the message from the constellation.

[gterzian]

I think you want to enqueue a task, because it will plug the task into the task-queue mechanism, which takes document activity into account. So if the target window is not fully active anymore, the script-thread handling the constellation message wouldn't be able to do anything with it.

If you enqueue a task, like is currently done, it will be added to the task-queue and executed if the not fully-active document becomes fully-active again later.

So the current behavior shouldn't be changed in my opinion.

[KiChjang]

Alternatively, the postMessage implementation on Window is ad-hoc and the spec in fact defines that the entire mechanism should really be managed through a MessagePort object as a field on Window. When we do get to the point where we can use MessagePorts, perhaps this issue would become obsolete.

[gterzian]

Related whatwg/html#3691