Intent to Implement and Ship Service Worker’s: ServiceWorkerMessageEvent, ExtendableMessageEvent

[xiang...@intel.com]

Contact emails

Engineering:

xiang...@intel.com

(PM: kenji...@chromium.org)

Spec

https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#serviceworkermessage-event-section

https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#extendablemessage-event-section

Summary

The change will introduce new message events between Service Worker and clients.

Motivation

MessageEvent is not a good fit for Service Worker since MessageEvent.source has type (Window or MessagePort). In Service Worker message communication model the messages sent from a client should have source as Client and messages sent from a Service Worker should have source as ServiceWorker. Also we'd like the message event received by Service Worker to be extended from ExtendableEvent so it has the ability to extend worker lifetime. When navigator.connect() API extends the communication model between cross origin service workers, the source attribute may also represent the MessagePort object from which the message is sent.

https://github.com/slightlyoff/ServiceWorker/issues/453

https://github.com/slightlyoff/ServiceWorker/issues/669

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28199

Compatibility Risk

We are following the spec which changed as a result of consensus on the Github issues linked above. These two message events have similar APIs with the exception of the source attribute. As a result, existing code would only be affected if it has explicit type checking or source null checking (.source is currently null: https://code.google.com/p/chromium/issues/detail?id=403693) . A more visible change is the messages sent from Client.postMessage will landed at the client’s navigator.serviceWorker instead of global scope.  Since a spec change in this direction was already anticipated, we have had an “experimental, may change” warning for Client.postMessage since M42: https://code.google.com/p/chromium/issues/detail?id=457094, currently there’s no use count data for this API because of: https://code.google.com/p/chromium/issues/detail?id=376039.

Ongoing technical constraints

None.

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

Yes.

OWP launch tracking bug?

http://crbug.com/403693.

Link to entry on the feature dashboard

Service Worker link: https://www.chromestatus.com/feature/6561526227927040

Requesting approval to ship?

Yes.

[Matt Falkenhagen]

This looks good to me (non-owner).

The patches for this change are already available:

https://codereview.chromium.org/1143543002/

https://codereview.chromium.org/1141813002/

https://codereview.chromium.org/1130113006/

[Philip Jägenstedt]

Can you convert http://crbug.com/403693 into an OWP launch tracking bug by changing the labels?

Given that the use counter doesn't work, do you have any guess as to how risky this change is? Is this something that early adopters of Service Workers are likely to have used, despite the warning? If it was the only way to achieve some important functionality, we should expect that people are using it.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Matt Falkenhagen]

2015-06-09 18:39 GMT+09:00 Philip Jägenstedt <phi...@opera.com>:

Can you convert http://crbug.com/403693 into an OWP launch tracking bug by changing the labels?

Done: https://code.google.com/p/chromium/issues/detail?id=498596

(made a new bug and duped the old one)

 

Given that the use counter doesn't work, do you have any guess as to how risky this change is? Is this something that early adopters of Service Workers are likely to have used, despite the warning? If it was the only way to achieve some important functionality, we should expect that people are using it.

Good question. I think it's low risk. Most of the production deployments we know of use SW exclusively for push notifications, which won't be affected by this change. The adopters are still small enough that we can contact them directly and use service-worker-discuss to announce the change.

[Philip Jägenstedt]

LGTM, it's a rare and precious thing when you can reach out to the affected sites directly :)

[Matt Falkenhagen]

Ping. This intent is still open.

[TAMURA, Kent]

Does it have any feedback from other browser vendors?

--

TAMURA Kent
Software Engineer, Google

[Matt Falkenhagen]

Yes, the decision was reached after discussions with Mozilla among others on the linked bugs. Ben Kelly of Mozilla says they believe they're ok with the current spec: https://github.com/slightlyoff/ServiceWorker/issues/669#issuecomment-106333033

[TAMURA, Kent]

ok, LGTM2.

[Matt Falkenhagen]

Ping. This intent is still < 3 LGTM.

[Chris Harrelson]

LGTM3