315804 2026-05-28 16:44:03 -0700 A `readwrite` IDBTransaction never fires oncomplete, onerror, or onabort after the user subscribes to web push in an installed PWA. 2026-05-30 13:36:13 -0700 1 1 1 Unclassified WebKit Website Storage Safari 26 Unspecified Unspecified NEW P2 Normal --- 1 sherwinhb webkit-unassigned beidson cdumez nham sherwinhb sihui_liu oldest_to_newest 2215531 0 sherwinhb 2026-05-28 16:44:03 -0700 WHAT'S HAPPENING ================ In an installed PWA (Add to Home Screen, display: standalone) on iOS 26, after the user subscribes to web push and then navigates to another same-origin page and back, the first `readwrite` IDBTransaction the page tries to open on one specific object store never completes. Reads on the same store still work, and reads/writes on other stores in the same database still work -- only `readwrite` on that one store is affected. Specifically: - db.transaction('Options', 'readwrite') returns an IDBTransaction normally. - tx.objectStore('Options').put(value) returns an IDBRequest normally. - The request's onsuccess and onerror never fire. - The transaction's oncomplete, onerror, and onabort never fire. - The database connection's onclose never fires. - After about 30 minutes the request finally resolves on its own, which I'm guessing is some internal timer aborting the transaction. If the page re-opens the database from scratch (indexedDB.open() -> fresh IDBDatabase), the new connection has the same behavior on that one store. So it's not a stale connection or proxy on the JS side. Opening a *different* IndexedDB database at the same origin and doing the same `readwrite` `put` works fine -- completes in about 11 ms. So the origin's IDB pipeline is healthy overall; it's just this one (database, object store, `readwrite`) combination that stops responding. Other things to note while the page is sitting there waiting: - All other JS keeps running normally -- timers fire, fetch works, the service worker stays responsive. - The service worker reports no open IDB transactions of its own. - The behavior continues even after the SW has been idle long enough for iOS to terminate it. So as far as I can tell it's not the SW holding anything open either. STEPS TO REPRODUCE ================== 1. On an iPhone (iOS 26), install a PWA that uses IndexedDB and the Push API. 2. From inside the PWA, navigate from page A to page B and back to page A. Confirm IndexedDB writes complete normally on both visits. 3. From inside the PWA, subscribe to push notifications (the page calls pushManager.subscribe() and the user grants permission). 4. Navigate to page B, then back to page A. 5. On step 4's return to page A, observe that the first `readwrite` `put` on a particular object store never fires any IDB lifecycle event. A working reproduction (two-page sandbox, dev server, ngrok instructions, expected vs. broken console output) is checked into this PR: https://github.com/OneSignal/OneSignal-Website-SDK/pull/1468 Full repro steps are in this comment: https://github.com/OneSignal/OneSignal-Website-SDK/pull/1468#issuecomment-4568334180 Steps 1-4 above are the only IDB-relevant trigger; everything else is just plumbing to expose a local HTTPS server to a real device. WHAT I TRIED ============ - Calling indexedDB.open() again before the affected `put`. Same behavior on the new connection. - Performing the same `readwrite` `put` on a separate database (indexedDB.open('different-db', 1)). Completes in ~11 ms. - Waiting for the service worker to go idle. Behavior persists. - Reads on the affected database/store keep working throughout. NOTES ===== - Only tested in the installed PWA case (display: standalone). I haven't tried to reproduce it in a regular Mobile Safari tab. - Symptom looks similar in shape to bug 226547 (silent indefinite hang with no events), but that one was on indexedDB.open() and was fixed in 14.6. - Probably unrelated to the connection-lost family (bug 273827, bug 277615, bug 309386), since we never get a close event or an UnknownError -- the request just never resolves. See Also: bug 226547, bug 309386 Happy to provide a sysdiagnose if helpful -- please let me know.