Bugzilla

Yes, this is still an issue due to WhatsApps Web using Firebase APIs which apparently require web APIs not available yet in Firefox Private browsing mode. I've taken a look here, and this is the check Firebase is failing to succeed on:
```
self && 'ServiceWorkerGlobalScope' in self
  ? 'indexedDB' in self &&
     null !== indexedDB &&
     'PushManager' in self &&
     'Notification' in self &&
     ServiceWorkerRegistration.prototype.hasOwnProperty('showNotification') &&
     PushSubscription.prototype.hasOwnProperty('getKey')
  : 'indexedDB' in window &&
     null !== indexedDB &&
     navigator.cookieEnabled &&
    'serviceWorker' in navigator &&
    'PushManager' in window &&
     'Notification' in window &&
    'fetch' in window &&
     ServiceWorkerRegistration.prototype.hasOwnProperty('showNotification') &&
     PushSubscription.prototype.hasOwnProperty('getKey')
```

So Firebase's messaging module seems to be designed to just assume that sites using it will always require Service Workers and IndexedDB to function.

I'm not sure that's actually the case, though. If I pause https://www.sbtnews.com.br/ while it loads, and define the objects like this, then I don't see any actual breakage on their main page:

```
window.indexedDB = {
  open: () => Promise.reject({ message:"" });
}
navigator.serviceWorker = {
   addEventListener() {},
   getRegistrations: () => Promise.resolve([]),
   register: () => Promise.reject({ message:"" })
 };
```

So it seems worth testing this further. With a simple webcompat shim like the above, we may be able to fix at least specific sites.

Yes, this is still an issue due to WhatsApps Web using Firebase APIs which apparently require web APIs not available yet in Firefox Private browsing mode. I've taken a look here, and this is the check Firebase is failing to succeed on:
```
self && 'ServiceWorkerGlobalScope' in self
  ? 'indexedDB' in self &&
     null !== indexedDB &&
     'PushManager' in self &&
     'Notification' in self &&
     ServiceWorkerRegistration.prototype.hasOwnProperty('showNotification') &&
     PushSubscription.prototype.hasOwnProperty('getKey')
  : 'indexedDB' in window &&
     null !== indexedDB &&
     navigator.cookieEnabled &&
    'serviceWorker' in navigator &&
    'PushManager' in window &&
     'Notification' in window &&
    'fetch' in window &&
     ServiceWorkerRegistration.prototype.hasOwnProperty('showNotification') &&
     PushSubscription.prototype.hasOwnProperty('getKey')
```

So Firebase's messaging module seems to be designed to just assume that sites using it will always require Service Workers and IndexedDB to function.

I'm not sure that's actually the case, though. If I pause https://www.sbtnews.com.br/ while it loads, and define the objects like this, then I don't see any actual breakage on their main page:

```
window.indexedDB = {
  open: () => Promise.reject({ message:"" });
}
navigator.serviceWorker = {
   addEventListener() {},
   getRegistrations: () => Promise.resolve([]),
   register: () => Promise.reject({ message:"" })
 };
```

So it seems worth testing this further. With a simple webcompat shim like the above, we may be able to fix at least specific sites.

I'm not at all sure if that will work for WhatsApp Web, though. Their page redirects like crazy, so we'll need to make an actual shim to test it, and odds seem good that they actually would use iDB or serviceworkers (whether or not they actually require them is the question).

Yes, this is still an issue due to WhatsApps Web using Firebase APIs which apparently require web APIs not available yet in Firefox Private browsing mode. I've taken a look here, and this is the check Firebase is failing to succeed on:
```
self && 'ServiceWorkerGlobalScope' in self
  ? 'indexedDB' in self &&
     null !== indexedDB &&
     'PushManager' in self &&
     'Notification' in self &&
     ServiceWorkerRegistration.prototype.hasOwnProperty('showNotification') &&
     PushSubscription.prototype.hasOwnProperty('getKey')
  : 'indexedDB' in window &&
     null !== indexedDB &&
     navigator.cookieEnabled &&
    'serviceWorker' in navigator &&
    'PushManager' in window &&
     'Notification' in window &&
    'fetch' in window &&
     ServiceWorkerRegistration.prototype.hasOwnProperty('showNotification') &&
     PushSubscription.prototype.hasOwnProperty('getKey')
```

So Firebase's messaging module seems to be designed to just assume that sites using it will always require Service Workers and IndexedDB to function.

I'm not sure that's actually the case, though. If I pause https://www.sbtnews.com.br/ while it loads, and define the objects like this, then I don't see any actual breakage on their main page:

```
window.indexedDB = {
  open: () => Promise.reject({ message:"" });
}
navigator.serviceWorker = {
   addEventListener() {},
   getRegistrations: () => Promise.resolve([]),
   register: () => Promise.reject({ message:"" })
 };
```

So it seems worth testing this further. With a simple webcompat shim like the above, we may be able to fix at least specific sites.

I'm not at all sure if that will work for WhatsApp Web, though. Their page redirects like crazy, so we'll need to make an actual shim to test it, and odds seem good that they actually would use iDB or serviceworkers (whether or not they actually require them is the question). And if they do, faking them may not be be a viable or useful solution for users.