Bug 91010

Summary: IndexedDB: Expose mechanism for database to force a connection to close
Product: WebKit Reporter: Joshua Bell <jsbell>
Component: New BugsAssignee: Joshua Bell <jsbell>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, alecflett, dglazkov, dgrogan, fishd, jamesr, michaeln, tkent+wkapi, tony, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch for landing none

Joshua Bell
Reported 2012-07-11 13:42:50 PDT
IndexedDB: Expose mechanism for database to force a connection to close
Attachments
Patch (11.69 KB, patch)
2012-07-11 13:50 PDT, Joshua Bell
no flags
Patch (17.34 KB, patch)
2012-08-15 15:24 PDT, Joshua Bell
no flags
Patch (17.50 KB, patch)
2012-08-22 17:17 PDT, Joshua Bell
no flags
Patch for landing (17.47 KB, patch)
2012-08-23 16:13 PDT, Joshua Bell
no flags
Joshua Bell
Comment 1 2012-07-11 13:50:58 PDT
Joshua Bell
Comment 2 2012-07-11 13:53:22 PDT
WebKit side of a fix for http://crbug.com/64050 - can't delete browsing data in Chromium port when a connection is open. Chromium side is: https://chromiumcodereview.appspot.com/10695158 This patch exposes a "forceClose" API that the back end can call on each connection to force it to close. In the Chromium port this is done in the browser itself which keeps track of these connections. I'm not sure where - if anywhere - to put WebKit side tests for this. I'm also not a fan of the name, so suggestions welcome.
Joshua Bell
Comment 3 2012-07-17 09:22:35 PDT
dgrogan@, alecflett@ - any comments? I should probably get this puppy landing. I'm still not happy with forceClose as a name. Maybe terminateConnection?
Alec Flett
Comment 4 2012-07-17 10:00:38 PDT
Comment on attachment 151765 [details] Patch LGTM - I like "forceClose" more..
David Grogan
Comment 5 2012-07-17 12:55:42 PDT
Comment on attachment 151765 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=151765&action=review LGTM. I haven't looked through the chrome patch yet. > Source/WebCore/Modules/indexeddb/IDBDatabaseCallbacksImpl.cpp:51 > + if (m_database) It's legitimate for m_database to be NULL here, this can't be an assert? > Source/WebKit/chromium/src/WebIDBDatabaseImpl.cpp:104 > + if (!m_databaseCallbacks) Does this only happen if forceClose is called twice?
David Grogan
Comment 6 2012-07-17 12:56:45 PDT
(In reply to comment #4) > (From update of attachment 151765 [details]) > LGTM - I like "forceClose" more.. Oh, and agreed. forceClose ftw.
David Grogan
Comment 7 2012-07-17 13:23:25 PDT
(In reply to comment #2) > I'm not sure where - if anywhere - to put WebKit side tests for this. We could add a method to window.internals/layouttestcontroller that simulates a forceClose, or just unit test it.
Joshua Bell
Comment 8 2012-07-25 14:37:38 PDT
Comment on attachment 151765 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=151765&action=review >> Source/WebCore/Modules/indexeddb/IDBDatabaseCallbacksImpl.cpp:51 >> + if (m_database) > > It's legitimate for m_database to be NULL here, this can't be an assert? Not sure what you mean... m_database can be NULL if the front-end has destructed, which can happen during script GC. Script may be the only thing holding an IDBDatabase alive; when script GC occurs the refcount drops to 0, and the destructor runs which closes the connection (an async call to the backend) and nulls out m_database in the CallbacksImpl. If there's a forceClose in flight from the backend to the frontend these could collide. So... it's legitimate for m_database to be NULL, so we can't assert. >> Source/WebKit/chromium/src/WebIDBDatabaseImpl.cpp:104 >> + if (!m_databaseCallbacks) > > Does this only happen if forceClose is called twice? Or a close followed by a forceClose, e.g. a close() is in-flight already from script when the UI triggers a forceClose(). On the Chromium side it looks like this class is retained in the dispatcher's map until the database backend is actually destroyed, so nothing earlier prevents that.
Joshua Bell
Comment 9 2012-08-15 15:24:39 PDT
WebKit Review Bot
Comment 10 2012-08-15 15:27:48 PDT
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
Joshua Bell
Comment 11 2012-08-22 17:17:33 PDT
Joshua Bell
Comment 12 2012-08-22 17:18:50 PDT
(In reply to comment #11) > Created an attachment (id=160039) [details] > Patch Rebase on top of the upgradeneeded changes. dglazkov@, abarth@ - review of the Chromium WebKit public API changes?
Adam Barth
Comment 13 2012-08-22 17:46:27 PDT
Comment on attachment 160039 [details] Patch API change LGTM
Joshua Bell
Comment 14 2012-08-23 10:15:59 PDT
tony@ - r?
Joshua Bell
Comment 15 2012-08-23 16:13:54 PDT
Created attachment 160273 [details] Patch for landing
WebKit Review Bot
Comment 16 2012-08-23 17:41:18 PDT
Comment on attachment 160273 [details] Patch for landing Clearing flags on attachment: 160273 Committed r126516: <http://trac.webkit.org/changeset/126516>
WebKit Review Bot
Comment 17 2012-08-23 17:41:22 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.