Intent to Deprecate and Remove: ServiceWorkerMessageEvent interface

[jungke...@samsung.com‏]

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:

 - HTML: https://github.com/whatwg/html/pull/1944

 - Service Workers: https://github.com/w3c/ServiceWorker/commit/6c68bd87bdfd153186a5b9904e31676c56730e2f

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.

Also see https://github.com/w3c/ServiceWorker/issues/989#issuecomment-255337272.

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

https://www.chromestatus.com/metrics/feature/popularity#DocumentCreateEventServiceWorkerMessageEvent

https://www.chromestatus.com/metrics/feature/popularity#ServiceWorkerClientPostMessage

https://github.com/w3c/ServiceWorker/issues/989#issuecomment-255337272

OWP launch tracking bug

https://crbug.com/659074

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‏]

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‏]

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‏]

I see. Still LGTM1 :)

[Rick Byers‏]

LGTM2

[Rick Byers‏]

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‏]

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‏]

Ah, thanks for catching that!  Done.

[jungke...@samsung.com‏]

tkent@, could you PTAL?

[Chris Harrelson‏]

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‏]

Thanks for review!

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