Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firestore persist breaks all of Firebase in Firefox Private Mode #801

Closed
avickers opened this issue May 10, 2018 · 9 comments

Comments

Projects
None yet
5 participants
@avickers
Copy link

commented May 10, 2018

[REQUIRED] Describe your environment

  • Operating System version: Mac OS
  • Firebase SDK version: 5.0.1
  • Firebase Product: Firestore

[REQUIRED] Describe the problem

You know all about the issues with Firefox Private Browsing and IndexDB, as you have already dealt with them for Auth. You have not, however, tested for private browsing mode, which admittedly Mozilla makes tricky, when enabling persistence for Firestore.

That throws
[2018-05-10T14:02:43.708Z] @firebase/firestore: Firestore (5.0.1): INTERNAL UNHANDLED ERROR: A mutation operation was attempted on a database that did not allow mutations. index.esm.js:77:12 defaultLogHandler index.esm.js:77:12 Logger</e.prototype.error index.esm.js:167:8 error index.esm.js:93:8 AsyncQueue</e.prototype.enqueue/n</< index.esm.js:12942:16

Which breaks the AsyncQueue, which breaks ALL the things.

Steps to reproduce:

Download Firefox. Enable Private Browsing Mode in preferences. Attempt to load a website that uses Firestore in persistence mode.

Relevant Code:

firebase.firestore().enablePersistence()
  .then(function() {
      // Initialize Cloud Firestore through firebase
      var db = firebase.firestore();
  })
  .catch(function(err) {
      if (err.code == 'failed-precondition') {
          // Multiple tabs open, persistence can only be enabled
          // in one tab at a a time.
          // ...
      } else if (err.code == 'unimplemented') {
          // The current browser does not support all of the
          // features required to enable persistence
          // ...
      }
  });

Additional Info

The expected behavior is that Firestore catches the error, simply launches without persistence enabled, and logs a warning to this effect.

This is something that has also long been an issue for PouchDB. Mozilla's philosophy is that the website shouldn't care whether a user is in PBM or not and features should just fail gracefully. They don't (or didn't?) make it easy to detect because that would just make it easy to work around tracking users.

For your consideration, the way I have always resolved this with PouchDB was to transparently proxy PouchDB to a web worker, which doesn't suffer from the IndexDB restrictions.

Such an approach would also address a couple other issues you have:

  • It would fix persistence for multiple tabs.
  • It's also quite nice in the single threaded environment to not block the DOM. Google is cheerleading the Progressive Web App movement, right? Why not let us build Firebase Apps more like Electron Apps and offload things out of the renderer thread. It can speed everything up as long as you handle the IPC well.
@wilhuff

This comment has been minimized.

Copy link
Member

commented May 10, 2018

The underlying Firefox bug seems to indicate this is uncatchable: https://bugzilla.mozilla.org/show_bug.cgi?id=781982#c62

We'll have a look, but another remedy would be to consider IndexedDB broken on Firefox and just disable persistence there rather than failing in private browsing mode :-(.

@avickers

This comment has been minimized.

Copy link
Author

commented May 10, 2018

IndexedDB is undefined in private browsing mode in Edge (Issue 9968399).

We'll have a look, but another remedy would be to consider IndexedDB broken on Firefox and just disable persistence there rather than failing in private browsing mode :-(.

Yeah, unless you guys come up with something ingenious, I imagine that's the only viable path for triage. +1 on the :-(, though.

If you would, please notify them on Bugzilla if you go that route. Maybe it will help wake them from their stupor.

@avickers

This comment has been minimized.

Copy link
Author

commented May 11, 2018

I came up with a hack-y way to detect Private Browsing Mode in FF59+.

Mozilla also disables serviceWorker in PBM; so in Firefox 59+, you can just check for 'serviceWorker' in navigator.

It might be better to wait for a proper solution from Mozilla, but thought I would throw it out there.

@mikelehen

This comment has been minimized.

Copy link
Member

commented May 11, 2018

Nice! Thanks for the tip. I guess for now you can do this manually in your app (and avoid calling .enablePersistence() if you detect Firefox Private Browsing). A proper solution from Mozilla would definitely be ideal but if we get more feedback on this and/or it doesn't look like Mozilla is going to solve this in a cleaner way anytime soon, we could look at including this in the SDK. Thanks!

@mikelehen

This comment has been minimized.

Copy link
Member

commented May 29, 2018

Closing for now, but we can re-open if more people run into this and we can come up with a sane way to detect Firefox Private Browsing.

@mikelehen mikelehen closed this May 29, 2018

@CodingDoug

This comment has been minimized.

Copy link

commented May 18, 2019

A workaround that works for my purposes is as follows:

    const db = indexedDB.open("foo")
    db.onsuccess = () => {
        this.firestore.enablePersistence().catch(error => {
            console.error('persistence error')
            console.error(error)
        })
    }
    db.onerror = () => { /* don't enable persistence */ }

One would probably want to wrap this up in a promise, and start querying only after it resolves.

Guided from:
https://stackoverflow.com/questions/2860879/detecting-if-a-browser-is-using-private-browsing-mode

@mikelehen

This comment has been minimized.

Copy link
Member

commented May 20, 2019

@CodingDoug Oh, interesting! Thanks for sharing that. From the discussion here I was under the impression that this wasn't easy to programmatically detect. But I guess it is. I've just opened a PR (#1801) to automatically degrade gracefully in this case.

mikelehen added a commit that referenced this issue May 20, 2019

@CodingDoug

This comment has been minimized.

Copy link

commented May 24, 2019

Works great for me now in 6.0.4, thanks!

@avickers

This comment has been minimized.

Copy link
Author

commented May 24, 2019

Thanks for sharing that @CodingDoug!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.