- From: Eliot Graff <Eliot.Graff@microsoft.com>
- Date: Thu, 7 Jul 2011 22:32:12 +0000
- To: Jeremy Orlow <jorlow@chromium.org>, Israel Hilerio <israelh@microsoft.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
For both IDBCursor.continue and IDBCursorSync.continue, Added one paragraph to the description: If you call this method multiple times, the cursor throws a NOT_ALLOWED_ERR exception and does not continue. If you catch the error you can then iterate through the cursor normally. Standardized the wording in the async and sync NOT_ALLOWED_ERR description to be: The cursor is currently being iterated, or has iterated past its end. Eliot From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Jeremy Orlow Sent: Monday, June 27, 2011 11:51 PM To: Israel Hilerio Cc: public-webapps@w3.org Subject: Re: [indexeddb] Behavior when calling IDBCursor.continue multiple times I thought it already was in there (or in some bug). But, if not, yeah it should just be documented. On Thu, Jun 23, 2011 at 2:32 PM, Israel Hilerio <israelh@microsoft.com> wrote: We noticed that the spec doesn't say anything about what needs to happen if IDBCursor.continue is called multiple times. We noticed that both FF and Chrome throw a NOT_ALLOWED_ERR exception. If the exception is not caught, the cursor doesn't continue to iterate, an error event is triggered (errorCode = ABORT_ERR), and the transaction is aborted. However, if the exception is caught, the cursor will iterate normally. This model makes sense to us. It seems this is something we should document on the spec. Do you agree? Israel
Received on Thursday, 7 July 2011 22:32:42 UTC