whatwg
Origin API: need to change MessageEvent
What is the issue with the HTML Standard?
@mikewest I missed this during review, but we need to change MessageEvent (and presumably ExtendableMessageEvent) so they also store the actual origin as an internal field.
Also, wouldn't it be better if we end up throwing for the cases where there is no true backing origin? When MessageEvent's origin is created from a string or when initMessageEvent() is called it seems that Origin.from() shouldn't work.
It seems we can enforce the above even better if we have a single "origin" field that holds null, a string, or an origin. (There are some challenges with this as we haven't really defined events properly thus far, but I think that's what we should strive for and allow implementations to do at least.)
For MessageEvent (and ExtendableMessageEvent), I think I'm on board with throwing instead of trying to mint an origin from a string. That has pretty good security properties, and seems like a reasonable precaution to remove one footgun developers might otherwise run into.
Holding a union of strings and origins sounds like a fine approach in the spec. (Though I guess I wonder how useful it is to allow strings to be carried around in the first place; we certainly have tests that depend on arbitrary strings, but I hope that's not actually load-bearing in the real world...)
