IndexedDB: Ignore open/delete requests from terminated renderers.

content/browser/indexed_db/indexed_db_database.cc

Index: content/browser/indexed_db/indexed_db_database.cc
diff --git a/content/browser/indexed_db/indexed_db_database.cc b/content/browser/indexed_db/indexed_db_database.cc
index c25f47e32d7f26dc9a0ca196482eaeb4075f5369..d4952ae170d446e2709f2725c69dbc19220be357 100644
--- a/content/browser/indexed_db/indexed_db_database.cc
+++ b/content/browser/indexed_db/indexed_db_database.cc
@@ -118,6 +118,11 @@ class IndexedDBDatabase::OpenRequest
       : ConnectionRequest(db), pending_(std::move(pending_connection)) {}
 
   void Perform() override {
+    if (!pending_->callbacks->IsValid()) {
+      db_->RequestComplete(this);
+      return;
+    }
+
     if (db_->metadata_.id == kInvalidId) {
       // The database was deleted then immediately re-opened; OpenInternal()
       // recreates it in the backing store.
@@ -290,6 +295,11 @@ class IndexedDBDatabase::DeleteRequest
       : ConnectionRequest(db), callbacks_(callbacks) {}
 
   void Perform() override {
+    if (!callbacks_->IsValid()) {

[cmumford, 2016/10/03 18:39:26]

I can see completing the open if disconnecting, but does this mean that if a
render process immediately closes after sending a delete request then that
request won't be implemented? This feels like something we'd still want to do.

[jsbell, 2016/10/03 19:28:37]

Could go either way, yeah. I decided this way for symmetry since we can't report
the delete as being successful and/or reporting data loss (although the renderer
could just crash later in the process, too - no guarantee the message ever gets
there).

How strongly do you feel about letting the delete proceed?

[cmumford, 2016/10/03 20:03:34]

My main worry is that a normal (i.e. not-crash) shutdown of a render process
could initiate the delete request and then shutdown before the IDB thread could
process the request. That has a privacy aspect to it, so my preference is to
honor the request even though the page is gone.

In all honesty I don't feel strongly about this, but wanted to point it out.

[jsbell, 2016/10/03 20:57:58]

That's a very good point, I hadn't considered that scenario. I agree we should
let deletes proceed.

+      db_->RequestComplete(this);
+      return;
+    }
+
     if (db_->connections_.empty()) {
       // No connections, so delete immediately.
       DoDelete();