Fix for non-sticky defaults bug. Added a bunch of tests.

chrome/browser/intents/web_intents_registry_unittest.cc

Index: chrome/browser/intents/web_intents_registry_unittest.cc
diff --git a/chrome/browser/intents/web_intents_registry_unittest.cc b/chrome/browser/intents/web_intents_registry_unittest.cc
index 156825ccd4bd52a0ac590b0bd2bd356f52e201fc..9506849f2c69faa1593659095934c736636fb512 100644
--- a/chrome/browser/intents/web_intents_registry_unittest.cc
+++ b/chrome/browser/intents/web_intents_registry_unittest.cc
@@ -596,6 +596,19 @@ TEST_F(WebIntentsRegistryTest, TestGetDefaults) {
   EXPECT_EQ(1, consumer.service_.user_date);
   EXPECT_EQ(4, consumer.service_.suppression);
 
+  // Can get for wildcard.

[Steve McKay, 2012/09/14 18:57:00]

Does this address the bug you're fixing, or are you just adding a wildcard case?
From the code change it looks like the user date was at issue.

Add a crbug id to the comment. Help's future maintainers NOT re-factor your test
in a way that looses the intended guarantees.

[Greg Billock, 2012/09/14 19:12:28]

No, this is just a useful test we were missing I discovered while investigating.
The NULL scheme is the root cause of the problem, and is fixed in two ways.

+  consumer.service_ = DefaultWebIntentService();
+  registry_.GetDefaultIntentService(
+      ASCIIToUTF16("share"),
+      ASCIIToUTF16("text/*"),
+      GURL("http://www.google.com/"),
+      base::Bind(&DefaultServiceConsumer::Accept,
+                 base::Unretained(&consumer)));
+  consumer.WaitForData();
+  EXPECT_EQ("service_url", consumer.service_.service_url);
+  EXPECT_EQ(1, consumer.service_.user_date);
+  EXPECT_EQ(4, consumer.service_.suppression);
+
   // Test that no action match means we don't retrieve any
   // default entries.
   consumer.service_ = DefaultWebIntentService();