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

Reply via email to