Pollyfill MessageEvent since Node doesn't initialize properties per the spec.

[kalvenschraut]

See my issue over on vitest

I could do a PR if all that would be done is what I did in its description.

[capricorn86]

Thanks for reporting @kalvenschraut! 🙂

MessageEvent has never been implemented.

You are very welcome to implement it. All contributions are welcome.

The event classes are here (you should find many example of how they are implemented by looking at other events):
https://github.com/capricorn86/happy-dom/tree/master/packages/happy-dom/src/event/events

[kalvenschraut]

Can I extend the global MessageEvent and add the missing functionality? Node doesn't do anything with the second parameter like it is suppose to per the spec. Can see what I am doing currently locally from the vitest issue.

[capricorn86]

@kalvenschraut the events in the browsers are expected to inherit from the Event, and it is not possible to extend two classes. Also, I believe they would have different purposes as the MessageEvent is meant for very browser specific functionality.

Do you have any documentation for the Node.js MessageEvent? Because I can't find it.

[kalvenschraut]

As far as I understood it, node is attempting to make MessageEvent available to behave like browser contexts, but it is missing the functionality that vitest is trying to use in their web worker package.

https://nodejs.org/api/globals.html#messageevent is the only documentation I can find.

Vlad at vitest talked that they could look at adding this themselves here

[capricorn86]

I think it is safest to implement this in Happy DOM without extending the NodeJS class to ensure that it will be compatible with the rest of the DOM functionality.

Example:

import Event from '../Event';
import IMessageEventInit from './IMessageEventInit';

export default class MessageEvent extends Event {
	public readonly data: string | null = null;
	...

	/**
	 * Constructor.
	 *
	 * @param type Event type.
	 * @param [eventInit] Event init.
	 */
	constructor(type: string, eventInit?: IMessageEventInit) {
		super(type, eventInit);
		this.data = eventInit?.data || null;

               ...
	}
}

[capricorn86]

By implementing this:
https://developer.mozilla.org/en-US/docs/Web/API/MessageEvent/MessageEvent

[kalvenschraut]

Apparently I was mistaken and Node's MessageEvent does work just fine as vlad reported and I just double checked.

The linked vitest issue only occurs with happy dom. No idea how happy-dom could be affecting this issue though.

[capricorn86]

It's probably because it has not been implemented in Happy DOM yet.

[kalvenschraut]

I guess I don't understand, if it hasn't been implemented in happy-dom then does it not fall back to Node's implementation?

node stackblitz

happy-dom stackblitz

The only difference between those two tests is the environment, one only has Node and other has happy-dom + Node.

Found Node's implementation here
Apparently Node is using symbols and then it defines a getter called data to get this symbol... interesting.

[kalvenschraut]

After looking into node's implementation a little bit more, they are defining those getters on the prototype specifically. Would happy dom be doing anything to overwrite the prototype to an empty object?

In node REPL

Then console.log'ing the prototype in happy-dom + vitest

[capricorn86]

@kalvenschraut I have made a fix which adds support for HTMLIframeElement, MessageEvent and Window.postMessage(). This should hopefully solve your issue 🙂

I have also added the logo for RTVision 🥳

You can read more about the release here:
#682