Intent to Deprecate and Remove: ServiceWorkerMessageEvent interface

90 vues
Accéder directement au premier message non lu

jungke...@samsung.com

non lue,
16 nov. 2016, 00:09:5216/11/2016
à 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

non lue,
16 nov. 2016, 03:56:1016/11/2016
à 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

non lue,
16 nov. 2016, 04:17:1816/11/2016
à 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

non lue,
16 nov. 2016, 04:58:2416/11/2016
à jungke...@samsung.com,blink-dev
I see. Still LGTM1 :)

Rick Byers

non lue,
17 nov. 2016, 11:00:0117/11/2016
à Philip Jägenstedt,송정기,blink-dev
LGTM2

Rick Byers

non lue,
17 nov. 2016, 12:01:3517/11/2016
à 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

non lue,
17 nov. 2016, 20:29:0717/11/2016
à 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

non lue,
17 nov. 2016, 20:37:1717/11/2016
à 송정기,blink-dev,Philip Jägenstedt
Ah, thanks for catching that!  Done.

jungke...@samsung.com

non lue,
30 nov. 2016, 21:02:0130/11/2016
à blink-dev,jungke...@samsung.com
tkent@, could you PTAL?

Chris Harrelson

non lue,
6 déc. 2016, 20:59:3806/12/2016
à 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

non lue,
8 déc. 2016, 01:03:1208/12/2016
à 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.

Répondre à tous
Répondre à l'auteur
Transférer
0 nouveau message