Save large icons to a new LARGE_ICON type

components/favicon_base/favicon_types.h

Index: components/favicon_base/favicon_types.h
diff --git a/components/favicon_base/favicon_types.h b/components/favicon_base/favicon_types.h
index 469d0fa10b9890fee0cb5a83dc0aa2d71e8999a7..3a30ef2b3311e9dec0cb8f1a877034460297755a 100644
--- a/components/favicon_base/favicon_types.h
+++ b/components/favicon_base/favicon_types.h
@@ -19,14 +19,29 @@ typedef int64 FaviconID;
 
 // Defines the icon types. They are also stored in icon_type field of favicons
 // table.
+//
 // The values of the IconTypes are used to select the priority in which favicon
 // data is returned in HistoryBackend and ThumbnailDatabase. Data for the
 // largest IconType takes priority if data for multiple IconTypes is available.
+//
+// Note that LARGE_ICON is a virtual icon type. In desktop environments, where
+// favicons are small by default and larger touch icons are not the norm, it
+// denotes the largest icon determined to be available. The underlying icon may
+// have originated as a large FAVICON, a TOUCH_PRECOMPOSED_ICON, or a
+// TOUCH_ICON. In mobile environments, larger sized icons are generally captured
+// by default, so additional LARGE_ICON tagged icons are not stored. The
+// LARGE_ICON type tag is only applied at the storage and query layers; icons
+// are recognized using their true underlying type and, if it is determined that
+// a large icon is desired but will not otherwise be captured, the backend
+// selects the best candidate and saves it using the LARGE_ICON type. When
+// querying for a large icon, all potential icon types are considered and the
+// returned results are evaluted based on the requested size.
 enum IconType {
   INVALID_ICON = 0x0,
   FAVICON = 1 << 0,
   TOUCH_ICON = 1 << 1,
-  TOUCH_PRECOMPOSED_ICON = 1 << 2
+  TOUCH_PRECOMPOSED_ICON = 1 << 2,
+  LARGE_ICON = 1 << 3

[sky, 2015/05/06 19:50:42]

Why do we need the new type?

[Roger McFarlane (Chromium), 2015/05/06 21:22:51]

The way the url-to-icon mappings are managed causes multiple representations of
the same IconType to step all over one another.

For example, if there two link-rel-icon entries in an html file one for 16x16
and one for 192x192, both get mapped to the FAVICON type in the DB. Say the
16x16 gets inserted first. When the 192x192 gets mapped, there is no good way to
determine whether or not it should replace the 16x16 or be added alongside it.
They both claim to be the FAVICON for the page.

The current mapping update logic causes the 16x16 would be unmapped and deleted.

 };
 
 // Defines a gfx::Image of size desired_size_in_dip composed of image