[webkit-reviews] review canceled: [Bug 92562] IndexedDB: IDBCursor.continue(key) does not throw for out of range key : [Attachment 155092] Patch

[bugzilla-daemon at webkit.org]

Joshua Bell <jsbell at chromium.org> has canceled Joshua Bell
<jsbell at chromium.org>'s request for review:
Bug 92562: IndexedDB: IDBCursor.continue(key) does not throw for out of range
key
https://bugs.webkit.org/show_bug.cgi?id=92562

Attachment 155092: Patch
https://bugs.webkit.org/attachment.cgi?id=155092&action=review

------- Additional Comments from Joshua Bell <jsbell at chromium.org>
View in context: https://bugs.webkit.org/attachment.cgi?id=155092&action=review


>> Source/WebCore/Modules/indexeddb/IDBCursorBackendImpl.cpp:45
>>
+IDBCursorBackendImpl::IDBCursorBackendImpl(PassRefPtr<IDBBackingStore::Cursor>
cursor, IDBCursor::Direction, CursorType cursorType, IDBTransactionBackendImpl*
transaction, IDBObjectStoreBackendImpl* objectStore)
> 
> I'm guessing IDBCursor::Direction is still used by IDBCursorBackendProxy?

No, it could be removed. (I rushed this patch a bit since it was a regression
and I was headed out.) The direction is passed through to the
IDBBackingStore::Cursor creation during the openCursor call, and the backend
cursor is passed in here. Turns out the IDBCursorBackend* no longer needs to
know about the direction at all. I can remove it. (I'll post an updated patch
on Wednesday.)

>> LayoutTests/storage/indexeddb/resources/cursor-continue-dir.js:55
>> +	    request.onsuccess = null;
> 
> What's going on with the request.onsuccess = null lines?

Debugging residue, I'll remove them. (Before fixing the bug the
cursor.continue() call was not throwing, so the test would infinite-loop if the
success handler was still around.)