Should MessageEvent.port really be nullable?

[cdumez]

Should MessageEvent.port really be nullable?

I don't understand why it is useful to have it be nullable and why its default value could not simply be an empty array.

This attribute is not nullable in WebKit and was not nullable in Blink until recently [1]. Thus, chances are it is web-compatible to have it not be nullable.

[1] https://chromium.googlesource.com/chromium/src/+/789b7be6bafd3d57fd747e0e8afe4218c7f025d7

[cdumez]

@foolip @bzbarsky @domenic

[bzbarsky]

I suspect this dates back to before IDL could have sequences defaulting to empty sequence or something...

At first glance, I see nothing preventing us from changing MessageEventInit to have:

sequence<MessagePort> ports = [];

and changing MessageEvent to have:

readonly attribute FrozenArray<MessagePort> ports;

@bakulf, any obvious problems with that? I think you last dealt with this stuff in Gecko...

[domenic]

Per http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4564 3/4 browsers have it as nullable. I don't really see the value in taking the longer path to compat instead of the shorter one...

[bakulf]

In Gecko, we can make it not nullable easily. No problem at all.

[cdumez]

@domenic Chrome had it nullable until fairly recently. What's the value of having this attribute / member nullable?

[domenic]

I don't see any particular value in either behavior. I am just wary of churning the spec (e.g. Chrome developers being unhappy that they made spec compliance changes only to get them reversed) and in making 3 engines change instead of 1.

[cdumez]

Well, I do think there is value in having it not nullable. It is nicer for Web developers as they don't have to worry about event.ports being null and can always assume it is an array. I don't think nullable arrays are a nice pattern in general.

I understand WebKit is the only one at this point not having it nullable and I will make it nullable in WebKit if people don't want to change the specification. However, doing this change makes me sad and I am hoping other engine developers would be willing to make this change, even if it is the longer path to interoperability, given that I think it would result in a nicer API.

[foolip]

It's easy to agree that what @cdumez suggests would be nicer, it'd also allow for the ports member to use [SameObject]. If @cdumez does the spec change, web-platform-tests and files an Edge bug, and @bakulf is on board with changing Gecko, then I volunteer for Blink.

CC @bashi who did the Blink change.

[cdumez]

I have never done a spec change but I guess there is a first time for everything :)

[cdumez]

PR at #1883

[bzbarsky]

it'd also allow for the ports member to use [SameObject]

No, because its value is not constant.

[domenic]

Isn't it? This is on the MessageEvent. It just returns the value it was initialized to.

[bzbarsky]

Yes, but initMessageEvent can change that value. That's its only job, really: to change all the values that stuff is initialized to.

[bzbarsky]

(I can claim no credit for noticing that, by the way; @smaug---- did.)

[foolip]

Ugh, well no [SameObject] then.

[foolip]

Test now available at https://w3c-test.org/html/webappapis/scripting/events/messageevent-constructor.html

Filed https://crbug.com/654707 for myself and https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/9293321/ for Edge, assuming @bakulf will handle Gecko.

AFAICT, only Gecko already required all of the arguments for initMessageEvent, so if anyone runs into the slightest trouble because of that, we should make as many of the arguments as possible optional, all except the first perhaps.

[smaug----]

So MessageEvent is now inconsistent with ServiceWorkerMessageEvent.
(I don't know why we even have the latter, when one could have just changed the union for .source, as far as I see)

[smaug----]

Note, ServiceWorkerMessageEvent has nullable .ports in Blink and Gecko

[foolip]

Uh, there's also ExtendableMessageEvent:
https://w3c.github.io/ServiceWorker/#extendablemessage-event-section

Not sure what to make of that, but leaving them inconsistent is no good. @cdumez, can you lobby to have the service worker spec changed? If it's more hassle than it's worth, we can always go back to nullable in HTML of course.

[cdumez]

Looks like @smaug---- already filed a bug against the Service Worker specification [1]. Let's see how this goes.

[1] w3c/ServiceWorker#989

[smaug----]

FWIW, since service worker events have nullable .ports both in implementations and in the spec, and also since majority of implementations have nullable .ports also on MessageEvent, and since nullability doesn't really cause any harm (and makes even sense in window.postMessage case, IMO), perhaps we should just stick with nullable ports everywhere.
Don't have strong opinion, but this all feels like a extra churn.

[annevk]

Non-nullable is a lot nicer though and service workers is still relatively fresh (and should probably change a bit here, the duplication seems rather hairy). But yeah, churn is not great.

[cdumez]

@smaug---- what do you mean by "makes even sense in window.postMessage case". I thought that postMessage() always created a FrozenArray even if there are no ports?

[smaug----]

oh, I was wrong about window.postMessage. nm that.

[smaug----]

Ok, so I think this change was just totally useless change, but since there is now a patch for Gecko, I won't object. ServiceWorker stuff is still inconsistent with this.

[jungkees]

I think HTML being able to change it means SW can also change it.

Non-nullable is a lot nicer

Out of curiosity, I would like to be convinced about this though.

since majority of implementations have nullable .ports also on MessageEvent

I'm also concerned about this. If HTML wants to stay with non-nullable, let me know. I think making them consistent would be the first choice.

[annevk]

I would like to be convinced about this though.

Basically, your code can assume it's an array. That's a lot better than first having to do a null-check.

I think the question with respect to service workers is how we can reduce some of the duplication going on with respect to classes.

[jungkees]

Basically, your code can assume it's an array. That's a lot better than first having to do a null-check.

Fair point.

I think the question with respect to service workers is how we can reduce some of the duplication going on with respect to classes.

Yeah, it'd be interesting to discuss if we can do better. Here's the discussion we'd had for your reference: w3c/ServiceWorker#669

I'll change the service worker's .ports conforming to HTML.

[cdumez]

Thanks @jungkees 👍

[jungkees]

Done with SW: w3c/ServiceWorker@8538a55 Thanks.

[annevk]

Closing this as OP is addressed. Further simplification is happening in #1944.