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.

What's the magic IDL I need to make the dictionary turn the value into a copy rather than a reference?

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).

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.

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.

heycam, should I reassign this to you in the meantime?

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?

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.

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

(Resolved as moved to https://github.com/whatwg/html/pull/863)