Intent to Implement and Ship: PostMessageOptions and WindowPostMessageOptions dictionary for postMessage methods

[Dave Tapuska]

Contact emails dtap...@chromium.org Spec https://github.com/whatwg/html/pull/3800 Summary Add an overload that takes a PostMessageOptions dictionary for ServiceWorker, Worker and Client. Add an overload that takes a WindowPostMessageOptions dictionary for Window. Motivation We'd like to add another attribute to Window.postMessage in https://github.com/dtapuska/useractivation and this is a prerequisite to clean up the postMessage APIs so that a dictionary can be used.

Interoperability risk Firefox: Mixed public signals Edge: No public signals Safari: Mixed public signals Web developers: No signals

No interop risk. Other vendors agree with the dictionary approach but have not provided support that they will follow.

Compatibility risk Feature detection is easy for Window by just checking the length of the method. However, for Worker, ServiceWorker, and Client, feature detection is more complicated. Ongoing technical constraints

None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Yes

OWP launch tracking bug https://crbug.com/861735 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/6219707585658880 Requesting approval to ship? Yes

[Matt Falkenhagen]

On Sat, Aug 11, 2018 at 5:19 AM, Dave Tapuska <dtap...@chromium.org> wrote:

Contact emails dtap...@chromium.org Spec https://github.com/whatwg/html/pull/3800 Summary Add an overload that takes a PostMessageOptions dictionary for ServiceWorker, Worker and Client. Add an overload that takes a WindowPostMessageOptions dictionary for Window.

Would you be able to provide examples of how developers can use this, especially for service workers and worker? The documentation at chromestatus links to the spec pull request which is hard to digest.

Also, are there web platform tests for this including for service workers, worker, and client?

Motivation We'd like to add another attribute to Window.postMessage in https://github.com/dtapuska/useractivation and this is a prerequisite to clean up the postMessage APIs so that a dictionary can be used.

Interoperability risk Firefox: Mixed public signals Edge: No public signals Safari: Mixed public signals Web developers: No signals

No interop risk. Other vendors agree with the dictionary approach but have not provided support that they will follow.

Compatibility risk Feature detection is easy for Window by just checking the length of the method. However, for Worker, ServiceWorker, and Client, feature detection is more complicated.

Can you elaborate on how it's more complicated for workers etc?

Ongoing technical constraints

None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Yes

OWP launch tracking bug https://crbug.com/861735 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/6219707585658880 Requesting approval to ship? Yes

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZUhPZaDehN8zJ0iv8YynX%3DXNogZBTRs1_NfAngSGzacTA%40mail.gmail.com.

[Dave Tapuska]

Basically the just of it is:

Writing code in the folowing syntax:

target.postMessage(message, {transfer: [a, b]};

as opposed to:

target.postMessage(message, [a, b]);

There are examples in the HTML spec change.

There are web platform tests for this as required by any specification changes.

Since workers and service workers don't have access to the window they can't query if a new postMessage is supported on Window. Which is the easiest way. For workers/serviceworkers/client they'd likely need to coordinate during setup or try calling thew new method and catch the exception.

An example (not sure if it is the best) might be; 

var new_post_message_supported = true;

try {

  myWorker.postMessage('post_mesage_supported', {});

} catch (e) {

 new_post_message_supported = false;

}

The worker would have to deal with accepting a 'post_message_supported' message value if it received it then it knows it can call the new fashion to return the results.

dave.

[Yoav Weiss]

A few questions:

* As you note, the feature detection mechanism in workers is clumsy and costly (triggers a message if successful, fires an exception if not). Have you looked into another channel? (e.g. "supports()"-like method)

* What would happen if developers fail to feature detect and test in non-supporting browsers?

  - Talking about this to +Philip Jägenstedt and +Alex Russell during the API owners call, this seems similar to the situation when shipping EventListenerOptions. Have there been any learnings from that in terms of backwards compat that we should take into account here?

  - Do we need an "official" polyfill that will bridge this gap for non-supporting browsers?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZUkZLMvVQMaYMOiQ6NFEtQGJ9krr3VS54e%2BhM4vpBSdCA%40mail.gmail.com.

[Anne van Kesteren]

On Fri, Aug 17, 2018 at 9:48 AM, Yoav Weiss <yo...@yoav.ws> wrote:
> * As you note, the feature detection mechanism in workers is clumsy and
> costly (triggers a message if successful, fires an exception if not). Have
> you looked into another channel? (e.g. "supports()"-like method)

It seems if all browsers implement this for all postMessage() methods
at the same time, which would be advisable anyway, you can use a dummy
MessageChannel. It's a little clumsy, but good enough.


--
https://annevankesteren.nl/

[Yoav Weiss]

Can you add an example for what that may look like?

 

--
https://annevankesteren.nl/

[Philip Jägenstedt]

Just to take an inventory of the scope here, there are 7 postMessage APIs, 5 defined in HTML and 2 in Service Workers.

https://github.com/w3c/ServiceWorker/pull/1344 is the PR for Service Workers, not linked here, but mentioned, so I take it the intention is to change them all one one go.

I believe that the interop risk here the main consideration, i.e. the risk that not all browser engines will come along for the ride. Dave, you linked to some discussion on https://github.com/whatwg/html/issues/3799, have you tried to seek feedback directly also? Although this whole change makes sense to me, postMessage is a pretty fundamental API, so extra prodding is warranted IMHO.

I see that the tentative tests are already merged, yay:

https://wpt.fyi/results/webmessaging/with-options?label=stable

https://wpt.fyi/results/webmessaging/with-options?label=experimental

(We have issues with timeouts in Edge.) I see that broken-origin.tentative.html is now actually failing in Chrome Dev, where it was passing before. Can you look into that? In either case, thank you for sharing your comprehensive tests early!

Aside about compat and fowards compat:

This is indeed structurally similar to EventListenerOptions and EventListenerOptions.passive, where an optional boolean became an optional (boolean or dictionary). There, the compat concern was whether existing content might already pass an object as the argument and depend on it evaluating to true, and there was also a "forwards compat" concern where new content using the feature would start breaking unnecessarily badly in browsers which didn't yet support it.

However, when you look at the details, the cases are quite different. The compat risk isn't high, because the suggested feature detect depends on postMessage(something, {}) throwing an exception before this change, so any such code out there is currently broken. It's possible that the site works anyway and that not throwing an exception will cause something to really break, but it's unlikely, and adding use counters couldn't tell if the change is good or bad, so let's just look out for regressions. Forward compat isn't much of a concern for similar reasons.

[Anne van Kesteren]

On Fri, Aug 17, 2018 at 10:23 AM, Yoav Weiss <yo...@yoav.ws> wrote:
> Can you add an example for what that may look like?

I now think there's a cleanish way that works for all postMessage() methods:

let supported = false
try {
postMessage("", { get transfer() { throw 1; } })
} catch(e) {
if(e === 1) {
supported = true
}
}
console.log(supported)


--
https://annevankesteren.nl/

[Dave Tapuska]

>I see that broken-origin.tentative.html is now actually failing in Chrome Dev, where it was passing before. Can you look into that? In either case, thank you for sharing your comprehensive tests early!

This test is actually intended to fail on Chrome because of issue crbug.com/660384 (webmessaging/without-ports/001.html fails the exact same way)

Anne, thanks for putting together the feature detection. I agree that should work!

I have tried soliciting explicit statements (in the github issue) from other vendors but haven't been successful in getting any firm commitments.

dave.

[Philip Jägenstedt]

LGTM1

Anne's feature detection is clever in that it will always throw an exception, so it won't risk confusing any listeners.

The other piece of uncertainty was implementer interest. No feedback on https://github.com/whatwg/html/issues/3799 yet, but Dave has filed https://github.com/w3ctag/design-reviews/issues/300 for the follow-on feature (thanks!) which will hopefully help bring this first change up on the radar as well. If we do get feedback from other vendors before or even after this reaches stable, we will of course take it seriously even there are 3xLGTM to ship on this thread.

[Rick Byers]

LGTM2

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYc%2BAEz6Z3UGMeBNhxnMh4HvCpG-0NzuzB20Xamys52U_g%40mail.gmail.com.

[Yoav Weiss]

LGTM3