Add a check to the registry before the intent infobar is shown.

chrome/browser/webdata/web_intents_table.cc

Index: chrome/browser/webdata/web_intents_table.cc
diff --git a/chrome/browser/webdata/web_intents_table.cc b/chrome/browser/webdata/web_intents_table.cc
index df7ec284c044c75f3a16b41247d0ca2501ea9e15..825ffe435bacf01c28a7a9424111e03020ec4b81 100644
--- a/chrome/browser/webdata/web_intents_table.cc
+++ b/chrome/browser/webdata/web_intents_table.cc
@@ -85,6 +85,24 @@ bool WebIntentsTable::GetWebIntents(
   return ExtractIntents(&s, intents);
 }
 
+bool WebIntentsTable::GetWebIntentsForURL(
+    const string16& action,
+    const string16& service_url,
+    std::vector<WebIntentServiceData>* intents) {
+  DCHECK(intents);
+  sql::Statement s(db_->GetUniqueStatement(
+      "SELECT service_url, action, type, title, disposition FROM web_intents "
+      "WHERE action=? AND service_url=?"));
+  if (!s) {
+    NOTREACHED() << "Statement prepare failed";
+    return false;

[James Hawkins, 2011/10/06 17:46:04]

Don't handle NOTREACHEDs by returning false. Leave the NOTREACHED and remove the
return (and the braces).

[Greg Billock, 2011/10/06 20:21:00]

In opt, NOTREACHED is just LOG(ERROR)

[James Hawkins, 2011/10/06 20:55:03]

Correct. Chrome style is to not handle DCHECKs and NOTREACHEDs by returning
early.  Better to crash then paper over an incorrect assertion.

[Greg Billock, 2011/10/06 21:37:57]

That's the thing; it isn't a strong assertion and won't crash in opt. Perhaps a
better plan would be to have a stronger NOTREACHED, but the DB code is pretty
full of this idiom, which I think is the correct behavior given the existing
meaning of NOTREACHED.

[James Hawkins, 2011/10/06 21:42:32]

You're missing the point. I realize NOTREACHED itself will not crash in opt;
however, the next few lines of code will crash, which is what we want in the
wild.

[Greg Billock, 2011/10/06 22:13:12]

I hear you, but see a lot of evidence that the opposite view is widely held. It
looks to me like the authors of /webdata use this pattern basically everywhere,
presumably for good reason. Perhaps these failures are more common than you'd
hope or something. Or used to be, and we should make a CL to take them out
uniformly. Creativity in dealing with DB errors is seldom advisable.

[James Hawkins, 2011/10/07 20:29:48]

They aren't common at all, and the returns for all of these need to be removed
(including other code that does the same thing).

See the very bottom of
https://sites.google.com/a/chromium.org/dev/developers/coding-style

[Greg Billock, 2011/10/07 23:00:48]

To the contrary, everywhere in /webdata NOTREACHED() is used, it is followed by
a similar return statement, with two exceptions: web_apps_table.cc:90, where the
code is already in a position where it should return true despite errors, and
web_data_service:667 where it is a void method and the last statement in the
method. As against about 150 instances of this pattern. They are common to the
point of ubiquity in this layer of the code.

That doesn't mean it isn't wrong; perhaps they're mostly copy-pasted from early
days and we should change it. I don't think striking out on our own here is a
good plan, though. A CL that strips this pattern sent to someone familiar with
the DB system would be better.

+  }
+
+  s.BindString16(0, action);
+  s.BindString16(1, service_url);
+  return ExtractIntents(&s, intents);
+}
+
 bool WebIntentsTable::GetAllWebIntents(
     std::vector<WebIntentServiceData>* intents) {
   DCHECK(intents);