Background sync fallback in Safari not working

Library Affected: workbox-background-sync

Browser & Platform: Safari 13

Issue or Feature Request Description: The fallback for browsers that don’t support background sync doesn’t appear to be working as expected in a PWA I am working on.

When offline, the request is added to the queue and I can see this in IndexedDB. However no event other than installing a new service worker (a solution that’s not workable in practice) will trigger the requests in the queue to be retried.

Looking in Queue.ts in workbox/packages/workbox-background-sync/src I can see on lines 413-415:

      // If the browser doesn't support background sync, retry
      // every time the service worker starts up as a fallback.
      this._onSync({queue: this});

this._onSync() only appears to be called the first time this._addSyncListener() is called but as it’s not attached to an event listener it’s never called again which would explain why it doesn’t work as I expected.

As a workaround I could make use of the replayRequests() function but before doing so I would like to confirm whether or not this behaviour is expected.

Here’s the service worker code (more or less a straight copy and paste from the Workbox docs):

  // Clone the request to ensure it's safe to read when
  // adding to the Queue.  
    const promiseChain = fetch(event.request.clone())
      .catch((err) => {
        self.clients.matchAll().then(all => all.map(client => client.postMessage("offline")));
  
        if(typeof BroadcastChannel !== "undefined") {
            const broadcastChannel = new BroadcastChannel('wb_channel');
            broadcastChannel.postMessage('offline');
        }
        return queue.pushRequest({ request: event.request });
      });
    event.waitUntil(promiseChain);
});

[jeffposnick]

https://github.com/GoogleChrome/workbox/pull/2955 exposes the QueueStore and StorableRequest classes publicly, and https://github.com/GoogleChrome/workbox/pull/2941 exposes the size() of the QueueStore used by a Queue. Both of those PRs should be part of the upcoming Workbox v6.4.0 release.

I’m going to be honest in that I have never had to work with those pieces of workbox-background-syncmanually, so I’m not complete sure if it addresses the use case you detail here. @tropicadri has worked with this portion of the Workbox codebase more recently and might have some insight to share.

[Adam-Reeves]

@philipwalton so will the fix of making the reply logic conditional on the registration succeeding fix the issues I’m having with Safari?