indexeddb versionchange event not fired

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Jake Archibald]

Visit http://jsbin.com/velolu/1/quiet
Open http://jsbin.com/pucegu/1/quiet in another tab
First tab should have versionchange event (compare to Firefox & Chrome).

Also getting some weird "unknownerror"s if I run this test a few times.

[Raymond Camden]

I can confirm this is a bug, but I want to add a bit of context. The bug is that if you have 2 tabs open using the same DB, and the second tab has upgraded the db, the first tab is not getting the event.

If, however, you use one tab, load the page, edit the code to change the version, and reload the page, the event is fired properly.

So this is more an issue of someone using the same DB concurrently. Probably a bit more rare, but should still be fixed.

[Radar WebKit Bug Importer]

<rdar://problem/20699757>

[Brady Eidson]

This works great in Modern IDB: Confirmed in the latest WebKit Nightly (r198511)

[Nolan Lawson]

I'm still able to reproduce the bug in WebKit Nightly r198834 - is that because I'm on Yosemite?

In the second tab, I don't see "Upgrading from version 1 / Connected to DB - you win!" Instead I just see "Database closed - go back to the other tab.", indicating the versionchange event wasn't fired.

I reproduced the correct behavior in both Chrome 49 and Firefox 47 for comparison. I also tested several times with different origins between each test.

[Brady Eidson]

(In reply to comment #4)
> I'm still able to reproduce the bug in WebKit Nightly r198834 - is that
> because I'm on Yosemite?

Nope - In fact Yosemite definitely wouldn't have the nightly issues that El Cap has been having.

> In the second tab, I don't see "Upgrading from version 1 / Connected to DB -
> you win!" Instead I just see "Database closed - go back to the other tab.",
> indicating the versionchange event wasn't fired.
> 
> I reproduced the correct behavior in both Chrome 49 and Firefox 47 for
> comparison. I also tested several times with different origins between each
> test.

Can you "remove all website data" then try again?

Or, more directly, with Safari/Nightly *not* running, do:
`rm -rf ~/Library/Safari/Databases/___IndexedDB/`
...then try again.

I can reproduce the correct behavior in a nightly at-will.

[Nolan Lawson]

I actually downloaded Jake's examples and ran them on localhost on multiple ports, so there ought to be no need to clear data. I tried five times and still couldn't reproduce the correct behavior.

I'm downloading El Cap and will try again...

[Brady Eidson]

(In reply to comment #6)
> I actually downloaded Jake's examples and ran them on localhost on multiple
> ports, so there ought to be no need to clear data. I tried five times and
> still couldn't reproduce the correct behavior.
> 
> I'm downloading El Cap and will try again...

There's no expected reason why this would be a Yosemite vs El Cap difference.

One other (stretch) thought - You're not trying in private browsing mode, are you?

[Nolan Lawson]

Nope, I wasn't in private browsing.

After upgrading to El Cap, I can confirm working in both WebKit Nightly r198834 and Safari Technology Preview 9.1.1 (11601.6.10, 11602.1.25). Not sure why it wasn't working in Yosemite (or if that was even my issue), but nice work! :)