Bug 39486 - Regression: Database origins aren't populated at launch (missing db in prefs sheet, possible other symptoms)
Summary: Regression: Database origins aren't populated at launch (missing db in prefs ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC All
: P2 Normal
Assignee: Brady Eidson
URL:
Keywords: InRadar, Regression
Depends on:
Blocks:
 
Reported: 2010-05-21 07:26 PDT by Adam Roben (:aroben)
Modified: 2010-06-17 01:38 PDT (History)
5 users (show)

See Also:


Attachments
Initialize a DatabaseTracker with it's initial path, instead of setting the path later. (8.60 KB, patch)
2010-05-21 17:09 PDT, Brady Eidson
beidson: commit-queue-
Details | Formatted Diff | Diff
Same thing, with Chromium build fix (9.41 KB, patch)
2010-05-21 17:31 PDT, Brady Eidson
darin: review+
beidson: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Roben (:aroben) 2010-05-21 07:26:23 PDT
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!
Comment 1 Adam Roben (:aroben) 2010-05-21 07:26:48 PDT
This happens on both Mac and Windows.
Comment 2 Adam Roben (:aroben) 2010-05-21 07:26:53 PDT
<rdar://problem/8013233>
Comment 3 Brady Eidson 2010-05-21 13:26:46 PDT
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.
Comment 4 Brady Eidson 2010-05-21 15:58:18 PDT
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.
Comment 5 Brady Eidson 2010-05-21 17:09:58 PDT
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.
Comment 6 WebKit Review Bot 2010-05-21 17:12:51 PDT
Attachment 56765 [details] did not build on chromium:
Build output: http://webkit-commit-queue.appspot.com/results/2312434
Comment 7 Brady Eidson 2010-05-21 17:31:46 PDT
Created attachment 56767 [details]
Same thing, with Chromium build fix
Comment 8 Brady Eidson 2010-05-24 15:47:01 PDT
Landed in http://trac.webkit.org/changeset/60092
Comment 9 Shinichiro Hamaji 2010-06-17 01:38:46 PDT
Looks like this issue was fixed?