Intent to Deprecate and Remove: ServiceWorkerMessageEvent interface

瀏覽次數:77 次
跳到第一則未讀訊息

jungke...@samsung.com

未讀,
2016年11月16日 上午12:09:522016/11/16
收件者: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

未讀,
2016年11月16日 上午3:56:102016/11/16
收件者: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

未讀,
2016年11月16日 上午4:17:182016/11/16
收件者: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

未讀,
2016年11月16日 上午4:58:242016/11/16
收件者:jungke...@samsung.com、blink-dev
I see. Still LGTM1 :)

Rick Byers

未讀,
2016年11月17日 上午11:00:012016/11/17
收件者:Philip Jägenstedt、송정기、blink-dev
LGTM2

Rick Byers

未讀,
2016年11月17日 下午12:01:352016/11/17
收件者: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

未讀,
2016年11月17日 下午8:29:072016/11/17
收件者: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

未讀,
2016年11月17日 下午8:37:172016/11/17
收件者:송정기、blink-dev、Philip Jägenstedt
Ah, thanks for catching that!  Done.

jungke...@samsung.com

未讀,
2016年11月30日 下午9:02:012016/11/30
收件者:blink-dev、jungke...@samsung.com
tkent@, could you PTAL?

Chris Harrelson

未讀,
2016年12月6日 下午8:59:382016/12/6
收件者: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

未讀,
2016年12月8日 上午1:03:122016/12/8
收件者: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.

回覆所有人
回覆作者
轉寄
0 則新訊息