23176 2013-09-06 16:19:48 +0000 Figure out what type MessageEvent.ports should be (array? frozen array? dedicated interface?) 2016-03-24 10:14:54 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED MOVED http://www.whatwg.org/specs/web-apps/current-work/#top blocked awaiting response from heycam to comment 6 (please remove this when replying) P3 normal Unsorted 23682 1 contributor philipj bashi bzbarsky cam ian mike philipj contributor oldest_to_newest 93122 0 contributor 2013-09-06 16:19:48 +0000 Specification: http://www.w3.org/TR/webmessaging/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Referrer: Comment: In the Event Definitions section, the .ports atribute of a MessageEvent is an IDL array. Given the way MessageEventInit is defined, this will be a writable array if the caller passes in a JS Array. I don't think it makes any sense to have a writable array here. Furthermore, it's not clear to me that we want an IDL array here at all. In terms of implementation, at least the Blink implementation doesn't do anything resembling what the spec calls for here. Further, it looks like the test suite simply doesn't have decent coverage of this stuff, based on a quick skim through http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/ and https://dvcs.w3.org/hg/webapps/rev/b5a2558005ab Posted from: 96.233.102.142 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0 93124 1 bzbarsky 2013-09-06 16:24:35 +0000 To be clear, in Blink you have: var a = new MessageChannel(); var b = new MessageEvent('message', { ports: [a.port1, a.port2] }); alert(b.ports == b.ports); alerting false. 93178 2 ian 2013-09-09 22:49:27 +0000 What's the magic IDL I need to make the dictionary turn the value into a copy rather than a reference? 93179 3 bzbarsky 2013-09-09 23:27:21 +0000 For the dictionary, sequence<MessagePort>. Possibly nullable if you want to allow explicit null (in which case presumably it should have a default value of null). What should appear in the interface depends on what you want the behavior to be, exactly. Chrome's current behavior is, as I said, insane. In Gecko we're making .ports on the event return a MessagePortList instance, with the MessagePortList interface defined in the obvious way (but probably NoInterfaceObject and ArrayClass). 95902 4 ian 2013-11-06 22:01:10 +0000 Why wouldn't we want the array on the event to be mutable? I agree it should be a copy of the one passed to the event constructor in the dictionary, not the same exact one. That's fixed by making the MessageEventInit member be a sequence<MessagePort>; that copies on the way in. So I've done that. But I'm not clear on why we can't just have an array on the way out. I really don't want to define a whole interface just to handle this, if we can help it. 95905 5 cam 2013-11-06 23:18:45 +0000 Bug 23682 suggests that .ports returns a frozen JS Array object, which sounds reasonable. Marking a dependency on that bug since we'll need to fix these array-like types before we can do this. Domenic suggested in IRC having a "frozen" keyword in the attribute definition to indicate this. So you'd have something like: [SameObject] readonly attribute frozen Array<MessagePort> ports; That's a lot of words. :) Still we might need to be careful about the automatic copying of values that the DOM spec does from the dictionary value to the Event object. I don't think we would write: dictionary MessageEventInit { frozen Array<MessagePort> ports; }; or at least, we wouldn't want to require that the object you pass in is already frozen. Remains to be seen what kinds of conversions this Array<MessagePort> type would do. 96267 6 ian 2013-11-13 22:57:17 +0000 heycam, should I reassign this to you in the meantime? 120471 7 bashi 2015-05-26 02:15:57 +0000 Should MessageEventInit.ports be nullable? Currently, https://html.spec.whatwg.org/multipage/comms.html#the-messageevent-interfaces says it is sequence<MessagePort>. If I read the the IDL spec correctly (correct me if I'm wrong), when we pass { ports: null } as MessageEventInit, a TypeError should be thrown. http://heycam.github.io/webidl/#es-dictionary http://heycam.github.io/webidl/#es-sequence - Gecko doesn't throw a TypeError and event.ports is initialized to null. - Blink doesn't throw a TypeError and event.ports is initialized to []. Blink's current behavior is wrong so I'd like to fix it. But it seems that Gecko doesn't follow what the spec says. I'd prefer to make MessageEventInit.ports nullable because MessageEvent.ports is nullable. It also matches the current Gecko's behavior. WDYT? 120472 8 bzbarsky 2015-05-26 02:33:15 +0000 Looks like in Gecko's current IDL the "ports" in MessageEventInit is of type "sequence<MessagePort>?". I agree that if null is a valid value for MessageEvent.ports then it should also be a valid value for the corresponding member of MessageEventInit. 125610 9 philipj 2016-03-24 10:13:50 +0000 https://github.com/whatwg/html/pull/863 will use FrozenArray<> here which solves most of what has been discussed here. What remains is the nullability of ports. It's only nullable because of initMessageEvent and MessageEventInit, AFAICT on all other paths it will be initialized to an array. This is a bit silly, but also harmless. Note that bashi@ made it nullable in https://chromium.googlesource.com/chromium/src/+/789b7be6bafd3d57fd747e0e8afe4218c7f025d7 and from my ad-hoc testing, Firefox Nightly and Chrome Canary now have the same behavior. If anyone thinks that it's worth investigating the compat impact of making ports non-nullable, please file a new issue at https://github.com/whatwg/html/issues 125612 10 philipj 2016-03-24 10:14:54 +0000 (Resolved as moved to https://github.com/whatwg/html/pull/863)