Intent to Deprecate and Remove: ServiceWorkerMessageEvent interface

96 views
Skip to first unread message

jungke...@samsung.com

unread,
Nov 16, 2016, 12:09:52 AM11/16/16
to blink-dev
Summary
Remove ServiceWorkerMessageEvent and use MessageEvent to fire message events to ServiceWorkerContainer objects and create custom message events.

Motivation
As ServiceWorkerMessageEvent and MessageEvent have the same interface definition except the type of the source atttriute, we aim to reduce this platform redundancy by replacing ServiceWorkerMessageEvent with the extended MessageEvent that allows ServiceWorker as a type of the source attribute.

Spec changes:

MessageEvent interface after the spec change: https://html.spec.whatwg.org/multipage/comms.html#messageevent

client.postMessage(message, trasfer) step 8.1 uses MessageEvent after the change: https://w3c.github.io/ServiceWorker/#dom-client-postmessage

Compatibility Risk
1. Contents creating a ServiceWorkerMessageEvent object using its constructor will raise a ReferenceError.
2. Contents creating a ServiceWorkerMessageEvent object by calling document.createEvent('ServiceWorkerMessageEvent') will throw a DOMException.
3. Contents checking event.type in navigator.serviceWorker.onmessage event listeners will get the value of 'MessageEvent' instead of 'ServiceWorkerMessageEvent'.

The usage counts for 2 and 3 are rounding to zero. The usage count for 1 is not measurable but expected to be very low.


Alternative implementation suggestion for web developers
Use MessageEvent interface instead of ServiceWorkerMessageEvent inteface to create a custom event.
Consider the message events received at navigator.serviceWorker are using MessageEvent interface instead of ServiceWorkerMessageEvent interface.

Usage information from UseCounter

OWP launch tracking bug

Entry on the feature dashboard

I don't seem to have a permission to create an entry. Here's the summary I propose:
```
Remove ServiceWorkerMessageEvent in favor of using MessageEvent
As HTML spec extended MessageEvent to allow ServiceWorker as a type of the source attribute, client.postMessage(message, transfer) and creation of custom message events are changed to use MessageEvent instead of ServiceWorkerMessageEvent.
```

Requesting approval to remove too?
Yes.

Philip Jägenstedt

unread,
Nov 16, 2016, 3:56:10 AM11/16/16
to jungke...@samsung.com, blink-dev
LGTM1.

Note that document.createEvent('ServiceWorkerMessageEvent') already throws, as of https://codereview.chromium.org/2217763003.

Is there a use counter for "Contents checking event.type in navigator.serviceWorker.onmessage event listeners" or why do you say usage rounds to zero? In any event this doesn't seem right, event.type would be 'message', to get the name of the event interface one would have to depend on event.toString() or perhaps Object.getPrototypeOf(event).constructor.name. Does not seem worth worrying about, but as always be prepared to revert.

jungke...@samsung.com

unread,
Nov 16, 2016, 4:17:18 AM11/16/16
to blink-dev, jungke...@samsung.com
On Wednesday, November 16, 2016 at 5:56:10 PM UTC+9, Philip Jägenstedt wrote:
LGTM1.

Note that document.createEvent('ServiceWorkerMessageEvent') already throws, as of https://codereview.chromium.org/2217763003.

Thanks for the pointer.
 

Is there a use counter for "Contents checking event.type in navigator.serviceWorker.onmessage event listeners" or why do you say usage rounds to zero? In any event this doesn't seem right, event.type would be 'message', to get the name of the event interface one would have to depend on event.toString() or perhaps Object.getPrototypeOf(event).constructor.name. Does not seem worth worrying about, but as always be prepared to revert.

That's right. Sorry for the confusion. I meant to say event.constructor would be 'MessageEvent'. And for mentioning usage rounding for zero was for postMessage rather than checking the interface name in the event listeners: https://www.chromestatus.com/metrics/feature/popularity#ServiceWorkerClientPostMessage.

Philip Jägenstedt

unread,
Nov 16, 2016, 4:58:24 AM11/16/16
to jungke...@samsung.com, blink-dev
I see. Still LGTM1 :)

Rick Byers

unread,
Nov 17, 2016, 11:00:01 AM11/17/16
to Philip Jägenstedt, 송정기, blink-dev
LGTM2

Rick Byers

unread,
Nov 17, 2016, 12:01:35 PM11/17/16
to Philip Jägenstedt, 송정기, blink-dev
Created an initial entry here: https://www.chromestatus.com/feature/5014379292524544.  Once this is approved / landed we can update with the milestone (presumably M57?).

jungke...@samsung.com

unread,
Nov 17, 2016, 8:29:07 PM11/17/16
to blink-dev, foo...@chromium.org, jungke...@samsung.com
Thanks for having created the entry. To clarify, I guess it'd be better not to add the last sentence: Removes https://www.chromestatus.com/features/5163630974730240. The works in the pointed entry include both ServiceWorkerMessageEvent and Client.postMessage() implementations the latter of which will still be there (internally using MessageEvent instead of ServiceWorkerMessageEvent.)

Rick Byers

unread,
Nov 17, 2016, 8:37:17 PM11/17/16
to 송정기, blink-dev, Philip Jägenstedt
Ah, thanks for catching that!  Done.

jungke...@samsung.com

unread,
Nov 30, 2016, 9:02:01 PM11/30/16
to blink-dev, jungke...@samsung.com
tkent@, could you PTAL?

Chris Harrelson

unread,
Dec 6, 2016, 8:59:38 PM12/6/16
to jungke...@samsung.com, blink-dev
LGTM3

Sorry this Intent took so long to approve.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

jungke...@samsung.com

unread,
Dec 8, 2016, 1:03:12 AM12/8/16
to blink-dev, jungke...@samsung.com, chri...@chromium.org
Thanks for review!
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Reply all
Reply to author
Forward
0 new messages