Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 63d90a92e5abed765bad3cb59b4dc7598d092c4d
https://github.com/WebKit/WebKit/commit/63d90a92e5abed765bad3cb59b4dc7598d092c4d
Author: Sihui Liu <[email protected]>
Date: 2026-07-20 (Mon, 20 Jul 2026)
Changed paths:
A
LayoutTests/storage/indexeddb/modern/cursor-unique-direction-empty-range-expected.txt
A
LayoutTests/storage/indexeddb/modern/cursor-unique-direction-empty-range-private-expected.txt
A
LayoutTests/storage/indexeddb/modern/cursor-unique-direction-empty-range-private.html
A
LayoutTests/storage/indexeddb/modern/cursor-unique-direction-empty-range.html
A
LayoutTests/storage/indexeddb/modern/resources/cursor-unique-direction-empty-range.js
M Source/WebCore/Modules/indexeddb/server/SQLiteIDBCursor.cpp
Log Message:
-----------
[IndexedDB] Opening a 'nextunique'/'prevunique' cursor over an empty key
range fails with an UnknownError
https://bugs.webkit.org/show_bug.cgi?id=319640
rdar://182231936
Reviewed by Rupin Mittal.
When opening an IDBCursor with 'nextunique' or 'prevunique' direction over a
key range that matches
no records, SQLiteIDBCursor::fetch() incorrectly reported failure instead of a
legitimate empty
result. Its dedup loop checked whether the newly fetched record's key differed
from
m_currentKeyForUniqueness before checking whether the fetch had reached the end
of the result set.
On a freshly created cursor, m_currentKeyForUniqueness is default-constructed
(Invalid type), which
compares equal to the terminal record's also-default-constructed key, so the
key-mismatch check did
not fire and control fell through to the completed check, which returned false.
SQLiteIDBBackingStore::openCursor() treated that false as cursor-creation
failure and surfaced an
UnknownError, even though a range with no matching records is a case the
IndexedDB spec requires to
succeed with a null result.
Check completed first, before the key-mismatch check, and return true in that
case, matching how the
non-unique (next/prev) path already reports end-of-results as success rather
than failure. This only
changes behavior for the empty-range case: whenever m_currentKeyForUniqueness
holds a real key from
a previously fetched record, the key-mismatch check already returned true ahead
of the completed
check, since a real key can never equal the terminal record's default Invalid
key.
Tests: storage/indexeddb/modern/cursor-unique-direction-empty-range-private.html
storage/indexeddb/modern/cursor-unique-direction-empty-range.html
*
LayoutTests/storage/indexeddb/modern/cursor-unique-direction-empty-range-expected.txt:
Added.
*
LayoutTests/storage/indexeddb/modern/cursor-unique-direction-empty-range-private-expected.txt:
Added.
*
LayoutTests/storage/indexeddb/modern/cursor-unique-direction-empty-range-private.html:
Added.
*
LayoutTests/storage/indexeddb/modern/cursor-unique-direction-empty-range.html:
Added.
*
LayoutTests/storage/indexeddb/modern/resources/cursor-unique-direction-empty-range.js:
Added.
(done):
(prepareDatabase):
(runNextTest):
(emptyIndexRange):
(emptyObjectStoreRange):
(testIndexCursor.request.onsuccess):
(testIndexCursor.request.onerror):
(testIndexCursor):
(testObjectStoreCursor.request.onsuccess):
(testObjectStoreCursor.request.onerror):
(testObjectStoreCursor):
* Source/WebCore/Modules/indexeddb/server/SQLiteIDBCursor.cpp:
(WebCore::IDBServer::SQLiteIDBCursor::fetch):
Canonical link: https://commits.webkit.org/317559@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications