Add Window.postMessage override that takes a dictionary

[dtapuska]

It is not possible to specify additional options to the postMessage method. I propose that we should change it so that it takes a dictionary.

Proposal from: https://github.com/dtapuska/useractivation

dictionary WindowPostMessageOptions {
  USVString targetOrigin = "/";
};

partial interface Window {
 void postMessage(any message, optional sequence<object> transfer = [],
                                optional WindowPostMessageOptions options);

};

[dtapuska]

Related issue is #1983

[domenic]

Folks, what do you think?

https://github.com/dtapuska/useractivation gives one motivation (see also #1983), wanting to add a new option to postMessage(). However, I'd argue that even without that motivation, this is a good idea for the platform and for web developers:

• It makes it so that you can more consistently do X.postMessage(data, transfer_opt, options_opt) throughout the platform. Currently there are 7 postMessage APIs, and, infuriatingly, all of them except Window conform to this pattern.
• It provides a nice safe default targetOrigin of "/", as opposed to the "*" I see recommended in lots of copy-and-paste-prone tutorials.
• window.postMessage(data, [t], { targetOrigin: "https://example.com/" }) is much more understandable to the reader than window.postMessage(data, "https://example.com/", [t]).

/ccing @smaug---- as I know he's been looking at https://github.com/dtapuska/useractivation. Then @travisleithead and @hober for Edge and Safari?

(I realize some folks might not find the implementation cost of this change in and of itself compelling, and might need to first be convinced of the value and design choices in https://github.com/dtapuska/useractivation. That's fine too. But with my editor and web developer hats on, I really want this change, independent of any future options we add to this dictionary.)

[dtapuska]

@smaug---- @travisleithead @hober Any thoughts on this proposal?

[rniwa]

@cdumez

[smaug----]

So far I haven't seen good reasoning why to change the old API.

[annevk]

Providing a consistent API is fairly compelling to me. I do wonder if requiring the transfer argument forever will turn out to be a mistake. That makes more sense as part of a dictionary to me.

[smaug----]

ok, fine, consistency would be good, and I agree transfer as a part of dictionary would be better, since it is often empty.

[dtapuska]

@annevk @smaug---- how does the latest revision look?

[annevk]

@dtapuska I haven't reviewed in detail, but that looks okay to me. I was worried that sequence and dictionary would not be https://heycam.github.io/webidl/#dfn-distinguishable but it seems they are so the other postMessage() methods could be similarly overloaded.

[cdumez]

So is the latest proposal:

partial interface Window {
  void postMessage(any message, optional sequence<object> transfer = [], optional WindowPostMessageOptions options);
};

or

partial interface Window {
  void postMessage(any message, optional WindowPostMessageOptions options);
};

with transfer being part of the options dictionary?

The previous comment from @smaug---- seemed to be in favor of making transfer part of the dictionary since it is optional and often empty. However, if we do so, then Window's postMessage is no longer consistent with other postMessage APIs, is it? It seemed like some people wanted that.

Personally, I do not believe that the consistency argument alone would be worth the trouble to implement this. I get that switching to a dictionary would be good if we added more options. However, we are currently not adding any options, are we? My preference would be to hold off on making a switch to dictionary until we actually need it (because we're adding options). It is unclear to me what those options will be (all other postMessage APIs do not require any options).

[dtapuska]

The current pull request is the later (transfer inside dictionary). If you see the user activation proposal that will be the dictionary entry we wish to add. But we've disassociated it from this post message change.

[smaug----]

If we do this, all the postMessages should have (any message, optional PostMessageOptions options) form.

[dtapuska]

That's fine. I can make pull requests against the other specs tomorrow if we agree on this.

[dtapuska]

@domenic I think I got the other spots. WDYT?

[foolip]

(I came here from Intent to Implement and Ship: PostMessageOptions and WindowPostMessageOptions dictionary for postMessage methods)

My preference would be to hold off on making a switch to dictionary until we actually need it (because we're adding options). It is unclear to me what those options will be (all other postMessage APIs do not require any options).

@cdumez, the intended addition is https://github.com/dtapuska/useractivation. The relevant bit there is the includeUserActivation member.

[travisleithead]

Late reply, but I support this--also glad to see transfer included in the dictionary as param 2.