Skip to content

IDBDatabase: explain why versionchange should close the connection - #46091

Open
ump45nose wants to merge 3 commits into
mdn:mainfrom
ump45nose:contrib/versionchange-is-super-important-and-har-26639
Open

ump45nose wants to merge 3 commits into
mdn:mainfrom
ump45nose:contrib/versionchange-is-super-important-and-har-26639

Conversation

@ump45nose

Copy link
Copy Markdown

Description

Expands the IDBDatabase: versionchange event page to explain why the event matters: an upgrade or deletion requested from another connection waits until every other connection is closed, closing the connection in the versionchange handler is the usual way to let it proceed, and the requesting side gets a blocked event while connections remain open. Replaces the examples with one that closes the connection in onversionchange and one that handles blocked on the requesting side. The one-line summary on the IDBDatabase page now says the handler should close the database.

Motivation

#26639 points out that the page barely explains versionchange, even though not handling it leaves another tab's upgrade stuck.

Additional details

Validation boundary: the behavior described follows the "open a database connection" / "delete a database" steps of the IndexedDB spec (fire versionchange at other connections, fire blocked if any remain open, wait for them to close) and the existing "Version changes while a web app is open in another tab" section, which the page now links to. I removed claims from an earlier draft about stale tabs silently corrupting data, because I could not source them. I did not run the examples in a browser or build the site locally.

Related issues and pull requests

Fixes #26639


AI assistance disclosure: this change was prepared with the help of an AI coding agent (Grok Bot) and has not been reviewed line by line by the account owner.

ump45nose and others added 3 commits October 5, 2026 05:19
The `versionchange` event page only said the event was "requested
elsewhere" and its examples just logged a message. It never said that
the upgrade is blocked until every other connection closes, or that an
open connection running an older schema is what makes running two
versions of the page in separate tabs corrupt data.

Add the multi-tab conflict explanation to the event page, covering
`blocked` on the requesting tab and why the usual response is to close
the connection and reload. Replace the two log-only examples with one
showing `db.close()` in the handler and one showing `onblocked` on the
requesting side. Also fix the `IDBDatabase` interface page's one-line
`versionchange` description, which had the same "requested elsewhere"
wording.

Fixes mdn#26639
@ump45nose
ump45nose requested a review from a team as a code owner October 10, 2026 09:24
@ump45nose
ump45nose requested review from wbamberg and removed request for a team October 10, 2026 09:24
@github-actions github-actions Bot added Content:WebAPI Web API docs size/m [PR only] 51-500 LoC changed labels Oct 10, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Content:WebAPI Web API docs size/m [PR only] 51-500 LoC changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

versionchange is super important and hardly is given any attention

1 participant