User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0.1) Gecko/20100101 Firefox/8.0.1 Build ID: 20111120135848 Steps to reproduce: I tried (in localhost) to store a record in my objectStore with put() when the user is prompted with a dialog to know wether he allows more than 50Mb to be stored. I tested when I don't answer the dialog box, and when I answer to not allow. Both behaviour have the same results. Actual results: Something very strange beyond my understanding: the onsuccess callback is triggered with no error. Inside the onsuccess callback I try to get the record from the store (with store.get(..) to make sure it was added), and very unexpectedly, the record is fetched. BUT I can say that the record wasn't saved (as expected), because I have a script displaying the content of all my objectStores, and I notice that the records trying to get inserted after the dialog prompt aren't present. So it's very curious that the record could be fetched at that moment. So the problem is that I can't find any way to detect a full quota, and worse, I can fetch the records that have been put() but they aren't saved, and this makes my database incoherent because I do other processing in case of success. Expected results: First of all, an error should be thrown after put() instead of onsuccess (QUOTA_ERR) Secondly, how could the record be fetched from the objectStore after the put(), as when I display the objectStore later on, the record isn't present? It seems there's a little mess going on when the limit is reached (when the user is prompted and didn't answer yet or when the user refused).

If I create a new transaction after the put(), before the get() to check wether the record has been inserted, then as expected it says the record isn't fetched. Thus, if you put() and the insert failed, and use get() right after within the same transaction, the record for some reason will successfully return, is this acceptable?

I think generally we won't write anything to disk until the transaction is committed, so we won't run into the 50MB limit until then. So at the time when the .put finishes things have in fact worked quite fine. If you try to add a onabort handler to the transaction object it should give you an event which indicates that there was a QUOTA_ERR. The transaction is then rolled back. This is why you can successfully read back the data during the actual transaction, since nothing has failed yet. But if you try to use a separate transaction to read back the data, then at that point the transaction has been rolled back and the data is no longer in the database. Let us know if this doesn't match the behavior that you are seeing?

This is the behaviour I have; I didn't know that I had to handle the case (where the user has reached the quota limit) at transaction level. Everything makes sense now. In the docs, QUOTA_ERR is documented in IDBRequest, under attribute errorCode. It seems to me that none of the requests get that errorCode, the error is only at transaction level. (https://developer.mozilla.org/en/IndexedDB/IDBRequest)

There's been discussions on the public-webapps list to add a transaction.error property specifically so that you can get information about errors that happen at commit-time rather than as a result from a specific transaction. That should take care of your problem.

Has transaction.error been added as stated on 2011-12-19? I am using Firefox 12 beta and having the same problem as Mathieu; I get an abort error (which I am causing on purpose by going over my quota for the sake of testing) but there is nothing in the event object that actually indicates a quota error. Has anything been done to solve this issue?

Same question as Mathieu: is the "QuotaExceededError" available in a future release ? Or is there a plan to support it ? (http://www.w3.org/TR/IndexedDB/#exceptions) I'm still not able to detect that a transaction failed because the quota is exceeded in the following situations: 1. reaching the quota while creating a new database - in FF13, the onerror handler on the open request is called with e.target.errorCode = 1 (UnknownError) - in FF14 (beta), the onerror handler is called but e.target has no errorCode property 2. reaching the quota while adding a new record - in FF13, the onabort handler on the write transaction is called with e.type = "abort" but no other useful information (errorCode...) - in FF14 (beta), same result Thanks for your feedback.

I guess the issue 767999 is answering my questions (https://bugzilla.mozilla.org/show_bug.cgi?id=767999). As of Firefox "16.0a1 (2012-06-27)" (currently Firefox Nightly), the exceptions carry more useful information. For example, you're adding a new record via a "store.add()" request, and reach the maximum quota allowed. The onabort handler is called on the transaction, and the provided exception (which I named "e") carry the following information : e.target.error.name => "QuotaExceededError". @Mathieu / @mborges : I think we'll have to wait for Firefox 16's release to take advantage of this change.

Update : "QuotaExceededError" works as expected if you reach the quota while adding a new record to an existing store, but not if you reach the quota while creating a new indexedDB database (see comments of issue https://bugzilla.mozilla.org/show_bug.cgi?id=767999).

Maxime: Can you file a separate bug on the issue of Quota errors not being fired as expected when the quota limit is reached while a database is being created? This bug is all over the place already so it would cause less confusion to have a bug focused only on that issue.

(In reply to Jonas Sicking (:sicking) from comment #9) > Maxime: Can you file a separate bug on the issue of Quota errors not being > fired as expected when the quota limit is reached while a database is being > created? This bug is all over the place already so it would cause less > confusion to have a bug focused only on that issue. Kyle filed a separate bug and fixed the issue : https://bugzilla.mozilla.org/show_bug.cgi?id=769537 Everything works like a charm now in Firefox 16.0a1 (2012-07-01) (currently Nightly). Thanks for fixing these issues!

It's 2015, Firefox 14 is unsupported. This was fixed by bug 769537.