In Chromium, postMessage() involves thread hops in a renderer, so there is a possibility that frame.remove() overtakes postMessage() (see c#6 on  issue 608464 ). In the case, postMessage() silently fails.

Our latest test does not hit this issue because it uses add_completion_callback to remove the frame. Maybe we should push it to the W3C repo.

I'm sympathetic since we had issues with this case as well, but as far as I can tell it should work according to the spec.  Getting this postMessage to work helped me fix some real bugs in our code.

I think we should keep this postMessage followed by frame.remove somewhere in the wpt test suite.  If you want to move it to a separate test case so it doesn't interfere with the respondWith test, that would be fine with me.  Does that sound reasonable?

Yes, it sounds good. Could you tell me where the spec is?

I'll send a PR like http://crrev.com/1859343002 and add the test into postmessage.https.html to keep track of the spec.

The spec is here:

  https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-postmessage

AFAICT it should start the SW and queue a task to fire the message event at it before returning.

> In Chromium, postMessage() involves thread hops in a renderer, so there is a possibility that frame.remove() overtakes postMessage() (see c#6 on  issue 608464 ). In the case, postMessage() silently fails.

This thread hop is gone thanks to MessagePort mojofication:
https://codereview.chromium.org/2422793002 (see the diff on web_service_worker_impl.cc)

navigator.serviceWorker.controller . omaraljabli 
https://codereview.chromium.org/2422793002


https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-postmessage

fetch-event-async-respond-with.https.html looks passing now.