Files
ladybird/Libraries/LibWeb/IndexedDB/Internal/Database.h
Zaggy1024 3c24a394c6 LibWeb: Refactor IndexedDB to handle requests serially
Previously, after one request was marked as processed, we would
synchronously queue another task to process the next request. This
would mean that two open requests on the same database could
interleave. This was especially problematic when one of the requests
would cause the database to upgrade, since the second open request
would begin processing before the upgradeneeded event fired, causing an
exception to be thrown in the second open().

The solution is to explicitly check for continuation conditions after
events have been fired in order to ensure that every step for the
request is completed before starting any further request processing.

For connection requests, the spec states:

> Open requests are processed in a connection queue. The queue contains
> all open requests associated with an storage key and a name. Requests
> added to the connection queue processed in order and each request
> must run to completion before the next request is processed. An open
> request may be blocked on other connections, requiring those
> connections to close before the request can complete and allow
> further requests to be processed.

For requests against a transaction, the spec states:

> Once the transaction has been started the implementation can begin
> executing the requests placed against the transaction. Requests must
> be executed in the order in which they were made against the
> transaction. Likewise, their results must be returned in the order
> the requests were placed against a specific transaction. There is no
> guarantee about the order that results from requests in different
> transactions are returned.

In the process of reworking it to use this approach, I've added a bunch
of new tests that cover things that our imported WPTs weren't checking.

With the fix for serializing connection requests, we can now fully
download the assets for the emscripten-compiled asm.js games in the
Humble Mozilla Bundle, particularly FTL: Faster Than Light.

There were no regressions in our test suite. One web platform test,
'idbindex_reverse_cursor.any.html', has one newly-failing subtest, but
the subtest was apparently only passing by chance due synchronous
execution of requests. A few web platform tests that were added in a
prior commit improved. The delete-request-queue.any.html test has
stopped crashing, and the close-in-upgrade-needed.any.html test has
stopped flaking, so they are both imported here as well.

Incidentally fixes #7512, for which a crash test has been added.
2026-03-05 17:12:55 -06:00

90 lines
3.5 KiB
C++

/*
* Copyright (c) 2024-2025, stelar7 <dudedbz@gmail.com>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <LibGC/HeapVector.h>
#include <LibGC/Ptr.h>
#include <LibWeb/DOM/EventTarget.h>
#include <LibWeb/IndexedDB/Internal/ObjectStore.h>
#include <LibWeb/StorageAPI/StorageKey.h>
namespace Web::IndexedDB {
// https://www.w3.org/TR/IndexedDB/#database-construct
class Database : public Bindings::PlatformObject {
WEB_NON_IDL_PLATFORM_OBJECT(Database, Bindings::PlatformObject);
GC_DECLARE_ALLOCATOR(Database);
public:
void set_version(u64 version) { m_version = version; }
u64 version() const { return m_version; }
String name() const { return m_name; }
void set_upgrade_transaction(GC::Ptr<IDBTransaction> transaction) { m_upgrade_transaction = transaction; }
[[nodiscard]] GC::Ptr<IDBTransaction> upgrade_transaction() { return m_upgrade_transaction; }
void associate(GC::Ref<IDBDatabase> connection) { m_associated_connections.append(connection); }
using AssociatedConnections = GC::HeapVector<GC::Ref<IDBDatabase>>;
GC::Ref<AssociatedConnections> associated_connections();
GC::Ref<AssociatedConnections> associated_connections_except(IDBDatabase& connection);
ReadonlySpan<GC::Ref<ObjectStore>> object_stores() { return m_object_stores; }
GC::Ptr<ObjectStore> object_store_with_name(String const& name) const;
void add_object_store(GC::Ref<ObjectStore> object_store) { m_object_stores.append(object_store); }
void remove_object_store(GC::Ref<ObjectStore> object_store)
{
m_object_stores.remove_first_matching([&](auto& entry) { return entry == object_store; });
}
[[nodiscard]] static Vector<GC::Weak<Database>> for_key(StorageAPI::StorageKey const&);
[[nodiscard]] static Optional<Database&> for_key_and_name(StorageAPI::StorageKey const&, String const&);
[[nodiscard]] static ErrorOr<GC::Root<Database>> create_for_key_and_name(JS::Realm&, StorageAPI::StorageKey const&, String const&);
[[nodiscard]] static ErrorOr<void> delete_for_key_and_name(StorageAPI::StorageKey const&, String const&);
static void for_each_database(AK::Function<void(Database&)> const& visitor);
[[nodiscard]] static GC::Ref<Database> create(JS::Realm&, String const&);
virtual ~Database();
void wait_for_connections_to_close(ReadonlySpan<GC::Ref<IDBDatabase>> connections, GC::Ref<GC::Function<void()>> after_all);
void check_pending_connection_wait();
protected:
explicit Database(IDBDatabase& database);
explicit Database(JS::Realm& realm, String name)
: PlatformObject(realm)
, m_name(move(name))
{
}
virtual void visit_edges(Visitor&) override;
private:
struct PendingConnectionWait {
Vector<GC::Ref<IDBDatabase>> connections;
GC::Ref<GC::Function<void()>> callback;
};
Vector<GC::Ref<IDBDatabase>> m_associated_connections;
Optional<PendingConnectionWait> m_pending_connection_wait;
// A database has a name which identifies it within a specific storage key.
String m_name;
// A database has a version. When a database is first created, its version is 0 (zero).
u64 m_version { 0 };
// A database has at most one associated upgrade transaction, which is either null or an upgrade transaction, and is initially null.
GC::Ptr<IDBTransaction> m_upgrade_transaction;
// A database has zero or more object stores which hold the data stored in the database.
Vector<GC::Ref<ObjectStore>> m_object_stores;
};
}