Bug 201169

Safari 12 implements the `ServiceWorkerContainer.startMessages()` API [1], but it does not actually implement the underlying buffering of messages sent from the service worker to the window in the `fetch` event for navigation requests [2]. Firefox has supported buffering for a while, and Chrome added support in M74 [3]. Prior to Chrome supporting this feature, we (on the Chrome team) recommended feature detecting support via the presence of the `startMessages()` method (since its purpose is to allow the buffer to start clearing before the DOMContentLoaded event): ``` if (navigator.serviceWorker && navigator.serviceWorker.startMessages) { // Assuming the service worker supports message buffering } ``` But given that Safari has the `startMessages()` method but does not implement the underlying buffering behavior, the above will result in a false positive, and it will likely mean lots of missed message from the service worker after navigation requests. The ability to reliably send a message from the service worker to the window after new navigations is important, as developers commonly rely on postMessage to inform the window that a newer version of the page exists [4]. If these messages are being dropped in Safari, then Safari users may be seeing outdated content and not receiving the message that new content is available. [1] https://w3c.github.io/ServiceWorker/#dom-serviceworkercontainer-startmessages [2] https://twitter.com/chris_dumez/status/1166170761125490689 [3] https://www.chromestatus.com/features/5751307839209472 [4] https://developers.google.com/web/tools/workbox/modules/workbox-broadcast-cache-update