Background-sync fallback not working in Chrome when Background Sync API is disabled

[nip10]

Library Affected:
workbox-background-sync

Browser & Platform:
Android WebView (Chrome Stable)

Issue or Feature Request Description:
The sw doesn't detect that the browser (Chrome) doesn't support (or has disabled) the Background Sync API, which results in both the BGS API and the fallback to not work.

The requests are added to the queue correctly (in IndexedDB) but the queue is never accessed/cleared.

Error:
Unable to register sync event for 'myQueueName'. DOMException: Background Sync is disabled.

Details:
Workbox v5.0.0
sw code is here, a basic example of the BGS package
Working on Chrome v80 (Windows 10 x64, and Android 10), using the BGS API
Working on Firefox v68.5.0 (Android 10) and Firefox v73.0.1 (Windows 10 x64), using the fallback (Firefox doesn't support the BGS API)
Not Working on Android WebView (Android 7, webview implementation: Chrome Stable, installed Chrome v80)

@philipwalton Here it is. Feel free to ask for more details and/or if you need me to debug further.

[imrans110]

Facing the same issue except with Electron rather than Android WebView. Any updates on this ?

[pat-flew]

Seems that simply checking for the presence of the sync property in
https://github.com/GoogleChrome/workbox/blob/3151c3a2740558b87a592f5091cc795815ca3ac5/packages/workbox-background-sync/src/Queue.ts#L363 is insufficient for these cases, as background sync is supported by the browser but disabled. Therefore, the check passes, an exception is thrown and the fallback never executes.

  /**
   * In sync-supporting browsers, this adds a listener for the sync event.
   * In non-sync-supporting browsers, this will retry the queue on service
   * worker startup.
   *
   * @private
   */
  private _addSyncListener() {
    if ('sync' in self.registration) {
      self.addEventListener('sync', (event: SyncEvent) => {
      // ...

[jeffposnick]

Apologies that there's hasn't been any activity on this since it was first reported.

I'm going to explore a few possible workarounds, including the feasibility of attempting a no-op sync registration wrapped in a try/catch in addition to the 'sync' in self.registration check.

[jeffposnick]

Hey All—Sorry again for the lack of progress.

I've been looking into this again, and I'm struggling with a "clean" solution here that detects the failure at runtime.

What I'm thinking instead is just to ship a new option in BackgroundSyncPlugin / Queue constructor called forceSyncFallback. The default value would be false, and that would give the same behavior as what we currently ship, with the 'sync' in self.registration check used to determine whether or not to use the sync event or the fallback. Developers could set this value to true if they knew that they were deploying to an environment that was subject to this bug—specifically, I'm thinking it would be useful for developers deploying to Electron, since you'd presumably have a dedicated build setup for that deployment scenario.

It would not address the situation with the old Android WebView user agents mentioned above, however.

Does this sound like it would be useful enough to unblock at least the Electron developers?

[BrendanOutform]

+1 for the update for Electron

[jeffposnick]

This is now available as an opt-in in https://github.com/GoogleChrome/workbox/releases/tag/v6.5.0