InvalidStateError in Firefox about localforage HOT 24 CLOSED

Thanks @thgreasi that is working for me in your example pen and by testing your branch in my own application. I had tried .stopPropagation() (didn't work) but got dragged away before trying out .preventDefault(). Thank you for investigating and resolving this!

I can't see any other side effects to this. Also, it sounds like FF's behaviour here is the "right" behavior with regards to propagating the errors to window.onerror (see "Integrate with window.onerror" in the w3c/IndexedDB spec) so it does look like this is the right thing to do.

Not directly related, but why does the .onerror handler reject with openreq.error rather than the error passed in to the handler?

from localforage.

Running the tests on Firefox 27 seems okay.

Is there any chance you could send me a reproducible JSFiddle or index.html page I could test it on? Also, what platform are you on? Windows, Mac, Linux?

from localforage.

This is most likely a problem with being in a Private window.
See https://bugzilla.mozilla.org/show_bug.cgi?id=919720#c1 and https://bugzilla.mozilla.org/show_bug.cgi?id=781982

from localforage.

Are you running this in a private browsing window, @coderaiser? I can't seem to reproduce this in Firefox 27 on Travis.

from localforage.

Yes, I running this on private browsing window.

from localforage.

Seems like it's problem in Firefox. On any site in private browsing window code:

indexedDB.open('hi')

shows InvalidStateError

from localforage.

Yeah, this is a bug in Firefox. Sadly, private browsing in a few browsers (iOS Safari, Firefox) mode mucks with storage a fair bit, but given it's super temporary anyway, I don't see it as a huge issue. I would almost think a kind of "dummy driver" for private browsing mode would be useful? But for now I'd track this issue on the bugs Peter mentioned.

from localforage.

I think would be great if localForage use localStorage or Websql if indexedDB could not open database.
Actually it's not important to me use always indexedDB. If we could not - it's OK to use something different. I thing localForage is created exactly for this purpose.

Also would be great if it was some versions. So everybody could know is new version is out.

from localforage.

The pull request #84 would help "catching" this bug and allow the promises to end with a reject

from localforage.

Looks like #448 should fix this one, but if not please let us know and reopen the issue. 😄

from localforage.

I'm still experiencing 'invalidState' error - Firefox in 'private mode'

Do you think @tofumatt that we should reopen this issue?

from localforage.

@karol-f what version of localforage are you using?
Trying this codepen in private mode on Firefox dev edition 48.0a2 fallbacks to the localstorage driver and succesfully retrieves the stored value.

from localforage.

Hi @thgreasi, I'm using latest (1.4.2). Your CodePen is indeed working - Private mode codepen

I'll check my code for race conditions and misconfigurations (I'm not setting drivers as you in Codepen, I'm not setting them at all).

Thank you for the response!

from localforage.

This is an example pen and we are only setting the driver preference order to ease experimentation.
Commenting out the setDriver() does not affect the result, since this is exactly what localforage does under the hood by default. Keep in mind that setting indexeddb as the only available driver will break the pen on Firefox Private Mode, since as you saw only localstorage is available on that environment.

from localforage.

@thgreasi your pen is exposing an InvalidStateError and also successfully writing and reading via localForage for me with FF 50.1.0+build2-0ubuntu0.16.04.1 in private browsing mode.

The order of the error is odd though; reading and writing happens fine and then afterwards the error is thrown (which is what I'm seeing in my own application).

from localforage.

I was unable to find a way to catch the error and while FF still seems to work (while generating annoying error messages), private mode in safari was failing completely.

Is there a correct way to catch this error and what's the correct way to detect that all storage engines have failed?

My interim workaround is just to avoid using localForage at all if window.indexedDB.init('test') fails; we're just using it as a cache so everything still works, just with more overhead than we would otherwise want.

from localforage.

what's the correct way to detect that all storage engines have failed?

The proper way is to check the error thrown as shown in this test case. The same error is thrown on all get/set/remove methods but I prefer to use ready().

from localforage.

Thanks @thgreasi, maybe .ready() should be added to the documentation? It does seem like a good idea to cover the case when no storage engines are available at all (e.g. safari in private browsing mode).

Unfortunately it doesn't prevent the uncaught error that I mentioned from bubbling up. I simplified your pen so that it only calls .ready() and then tries to .catch() and log the error, however the .ready() is not rejected (the console.log() in .then() is called instead) and there is still an uncaught error getting logged to the console. This is in FF private browsing mode.

The same uncaught error can be seen in your original pen, as I showed in the screenshot above.

It looks like the fallback is actually working, as local storage is used instead, however an error from the failed attempt at using indexeddb is not being caught as it should be and so does get exposed.

from localforage.

I really can't see anything wrong with what localforage is doing though, so perhaps this is a FF bug?

Ultimately the failure to connect is calling the window.onerror which we use for logging any uncaught errors in our app; it's generating useless noise for us in this case as the error is expected and has already been handled.

from localforage.

Adding a e.preventDefault(); call inside the indexedDB.open().onerror() handler seems to prevent the error from reaching window.onerror(). Sample codepen. Any chance this might have other side effects?

from localforage.

@elyobo thanks for your commitment on this so far.
I just opened PR #648 that possibly resolves this.
As soon as you can confirm that this works for you, we can merge it in for v1.5 .

from localforage.

I'm not sure, aren't they referencing the same object?

from localforage.

Did you got any weird results on other browsers?

from localforage.

from localforage.