To reproduce: 1. Go to http://webkit.org/misc/DatabaseExample.html 2. Make a few notes 3. Go to Preferences > Security > Show Databases No databases are listed. But there should be a database for webkit.org!
This happens on both Mac and Windows.
<rdar://problem/8013233>
The first major cause I've found is http://trac.webkit.org/changeset/57668. Things happen like this: -On launch, WebKit initializes databases in WebKitInitializeDatabasesIfNecessary() -In that method the first thing it tries to do is: DatabaseTracker::tracker().setDatabaseDirectoryPath(databasesDirectoryPath()); -In r57668, populating the origins was moved to the constructor. Other than rote refactoring, it's not immediately clear to me why this was necessary. -So when that initialization code runs, it creates the tracker, whose c'tor tries to populate the origins, but the database path hasn't been set, so that fails. And after it fails once the tracker is in a pretty bogus state. The fix for this might be very, very easy, but I can't get to it for an hour or two.
There was a lot of changes and refactoring done in database code that I didn't pay super close attention to, but I think the change to move populateOrigins() into the constructor was misguided, since it forced origin populate on startup for at least 2 ports - even if databases are never to be used.
Created attachment 56765 [details] Initialize a DatabaseTracker with it's initial path, instead of setting the path later. I can test this in DRT to make sure it doesn't break again but doing so will require an API-specific test. I plan to followup this patch with that, as this bug is keeping us from doing real work in the short term.
Attachment 56765 [details] did not build on chromium: Build output: http://webkit-commit-queue.appspot.com/results/2312434
Created attachment 56767 [details] Same thing, with Chromium build fix
Landed in http://trac.webkit.org/changeset/60092
Looks like this issue was fixed?