MessageEvent within the SW global should have waitUntil()

[jakearchibald]

Not sure how to easily mix this in, but the SW should be able to signal it's doing work after a postMessage

self.onmessage = function(event) {
  event.waitUntil(
    doAsyncStuff.then(response => event.source.postMessage(response))
  )
};

Or we could revisit a global waitUntil #400. We'd need to call it something different though, I'm worried devs may use waitUntil() instead of event.waitUntil() and get different behaviour because success/failure doesn't reach the event dispatcher.

[wanderview]

If we don't do a global, can we maybe have a mix-in interface that all SW events implement? Seems things like background sync, push, etc would want this to.

[jakearchibald]

We already have that - ExtendableEvent if memory serves

On Wed, 1 Apr 2015 17:06 Ben Kelly notifications@github.com wrote:

If we don't do a global, can we maybe have a mix-in interface that all SW
events implement? Seems things like background sync, push, etc would want
this to.

—
Reply to this email directly or view it on GitHub
#669 (comment)
.

[wanderview]

Ah, true. I guess it just has the install event extra logic embedded in there, though.

https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#extendable-event

[jungkees]

install/activate events are just using ExtendableEvent interface without any extra logic for them, and other functional events can extend it.

[annevk]

So we don't want it on the global because that encourages global reasoning rather than event-based reasoning, right? I think that's still applicable.

Perhaps we should just bite the bullet and introduce ServiceWorkerMessageEvent/ClientMessageEvent. With ClientMessageEvent (dispatched inside service workers) inheriting from ExtendableEvent.

[wanderview]

It would be nice if we could do something about MessageEvent soon. The web-platform-tests use MessageEvent and I think some of our intermittent failures are due to the ServiceWorker shutting down before the test completes. We really need a .waitUntil() to keep the worker alive.

[jungkees]

Addressed: cc117a0.

I tried to name it ExtendableMessageEvent rather than ClientMessageEvent as the message events sent by ServiceWorker.postMessage() include service worker to service worker communication (e.g. installing worker to active worker). I feel it sounds intuitive too. For the messages sent by Client.postMessage(), I just used ServiceWorkerMessageEvent. Any better name for this interface?

[jakearchibald]

Naming sounds fine to me. Cheers!

[mfalken]

Should ServiceWorkerMessageEvent inherit from MessageEvent and ServiceWorkerMessageEventInit from MessageEventInit? This came up in a codereview: https://codereview.chromium.org/1130113006/#msg17

[jungkees]

I replied to the codereview discussion: https://codereview.chromium.org/1130113006/diff/60001/Source/modules/serviceworkers/ServiceWorkerMessageEventInit.idl#newcode7

Also, ServiceWorkerMessageEventInit has been removed by #701.

[mfalken]

OK Blink is likely going ahead with the current spec and we'll be preparing an Intent to Ship. @wanderview is Mozilla ok with the spec?

[wanderview]

@wanderview is Mozilla ok with the spec?

We haven't started implementing it yet, as far as I know. I believe we are ok with the current spec, though.