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 [email protected] 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.

[mfalken]

Is there a point to "lastEventId"? I guess it's only for backwards compatibility with MessageEvent, and it will always be the empty string unless you've manually constructed a ServiceWorkerMessageEvent, right?

[jungkees]

Right. ServiceWorkerMessageEvent is not a MessageEvent indeed. And it seems MessageEvent.lastEventId is only used for server-sent event as well. I think we can remove it unless it has some conventional usage among devs which I doubt.

[mfalken]

For that matter is |origin| useful? It would always be your origin as SW must be same-origin.

[jungkees]

navigator.connect wants to use ServiceWorkerMessageEvent and ExtendableMessageEvent for cross-origin communication: mkruisselbrink/navigator-connect#39 (comment).

[annevk]

That shouldn't use the same event though.

[jungkees]

Could you explain why? Those interfaces are defined for the message events dispatched during service worker communications in general. Using the same interfaces seems fine.

[mfalken]

Oops, this should be v1 since Chrome already implements it.

Can we get resolution here?

[wanderview]

I believe @annevk's comment was in regard to:

navigator.connect wants to use ServiceWorkerMessageEvent and ExtendableMessageEvent for cross-origin communication

That's certainly not a v1 issue.

In regards to:

For that matter is |origin| useful? It would always be your origin as SW must be same-origin.

I think it could be useful for library code that may not know exactly what SW it was invoked in. If we want to remove it for now, though, we can always add it later.

@matto, did you end up implementing the origin attribute?

[kinu]

@wanderview @mattto yes Blink's ServiceWorkerMessageEvent implements/exposes the origin attribute.

[wanderview]

I think we can close this then as the current spec is whats implemented. I don't see a strong reason to change now.

[rjfioravanti]

I'm pretty confused what the current state of this is. I cannot figure out how to respond to a message event in a service-worker with async work, and make sure the work actually stays alive. Both this and #400 were closed as "will not do anything" IIUC. Doesn't this make every onmessage event handler for service-workers vulnerable to bugs due to dying before completion?

[wanderview]

We do now have a message event that included waitUntil():

https://w3c.github.io/ServiceWorker/#extendablemessageevent-interface

Which extends:

https://w3c.github.io/ServiceWorker/#extendableevent