15063 2011-12-05 16:42:09 +0000 each MessageChannel acts as its own task source. This means that messages sent using this function are not guaranteed to execute in order, since the order task sources are processed isn't specified. 2013-01-29 20:59:21 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#message-ports P3 normal Unsorted 1 contributor ian ian james mike zcorpan contributor oldest_to_newest 60947 0 contributor 2011-12-05 16:42:09 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html Multipage: http://www.whatwg.org/C#message-ports Complete: http://www.whatwg.org/c#message-ports Comment: each MessageChannel acts as its own task source. This means that messages sent using this function are not guaranteed to execute in order, since the order task sources are processed isn't specified. Posted from: 85.227.157.105 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/535.8 (KHTML, like Gecko) Chrome/17.0.942.0 Safari/535.8 60948 1 zcorpan 2011-12-05 16:43:40 +0000 The above is quoted from https://www.w3.org/Bugs/Public/show_bug.cgi?id=15007#c18 I think it's a problem. We shouldn't let the order be unspecified for ports within a single window (or worker). 61176 2 ian 2011-12-07 23:38:56 +0000 Why is this a problem? Seems pretty reasonable to me. Implementations should be allowed to implement all message channels by routing messages through a central dispatch process, and if we do that there's no way to really make channels that happen to have both ports in one process magically be ordered relative to each other. 61225 3 zcorpan 2011-12-08 09:34:39 +0000 Because people have used multiple MessageChannels as a way to implement "queue a task" polyfill (which they want to execute in order), and they do execute in order in Opera and Chrome today. If we change it to not execute in order, sites using such polyfills would break sometimes in hard-to-debug ways. 61275 4 ian 2011-12-09 00:29:12 +0000 I am highly skeptical that the order is actually guaranteed in Chrome today, especially around the time if and while one were to send the port across processes and back. 61299 5 zcorpan 2011-12-09 12:19:54 +0000 The polyfills don't send the ports to other processes, though. When a port is sent to somewhere else (and possibly back again), I'm fine with order being arbitrary. 61350 6 ian 2011-12-09 23:06:38 +0000 Hmmm... So you're saying the order should be defined only amongst ports that have been created by a MessageChannel and not yet ever been sent over another channel... I guess we can do that, though it'll be really convoluted to spec... 70535 7 contributor 2012-07-18 16:01:39 +0000 This bug was cloned to create bug 18033 as part of operation convergence. 71586 8 ian 2012-07-27 06:00:36 +0000 If there's any way to get out of speccing this, I'd love to take it... 72119 9 james 2012-08-13 12:22:03 +0000 I think I agree with Simon here; there will be compat constraints on message ordering. I wonder if it is OK to make a design that assumes order can be preserved for each unit of related browsing context. Then each unit of related browsing context could have two associated task queues; one for same-unit messages and one for different-unit messages. Messages from the two queues might interleave, and messages from the other-unit queue might not have a well-defined order, but messages from the same-unit queue would. Basically this is equivalent to the "central dispatch server" design, but with a spec-mandated optimisation that as long as you are not going outside your own related browsing context neighborhood you don't go through the seperate server but instead straight into a local queue. 75906 10 ian 2012-10-10 23:52:37 +0000 That's more or less what I had in mind earlier when I said it'd be convoluted to spec (and probably implement). But I think there's a simpler solution: How about we just make each port have a flag that tracks if it or its paired port have ever gone through another port. While that flag isn't set (i.e. both ports are still in the same unit of related browsing contexts (henceforth "unit") as the original message channel), then you use a unit-global task source shared with all the other MessagePort objects with the flag set in the same unit. But if you ever send a port through another port, then both the sent port and its paired port, as well as the new port on the other end when the port comes out, have the flag set, and then they start using their own task source just for themselves. 75941 11 zcorpan 2012-10-11 06:53:53 +0000 That sounds OK. 76769 12 ian 2012-10-19 22:27:20 +0000 *** Bug 18033 has been marked as a duplicate of this bug. *** 82309 13 contributor 2013-01-29 20:59:21 +0000 Checked in as WHATWG revision r7669. Check-in comment: Make MessagePort objects synchronised until they are posted through another port. http://html5.org/tools/web-apps-tracker?from=7668&to=7669