Find Favicon in priority of icon_type.

chrome/browser/history/history_backend.h

Index: chrome/browser/history/history_backend.h
diff --git a/chrome/browser/history/history_backend.h b/chrome/browser/history/history_backend.h
index f3bbf4d9ebe943189c1f474a278211ef77a83d2d..d7b97dc6b931c85c35c31d03d847aa37cb64cb1e 100644
--- a/chrome/browser/history/history_backend.h
+++ b/chrome/browser/history/history_backend.h
@@ -244,9 +244,10 @@ class HistoryBackend : public base::RefCountedThreadSafe<HistoryBackend>,
 
   void GetFaviconsForURL(
       const GURL& page_url,
-      int icon_types,
+      const std::vector<int>& icon_types_priority,

[sky, 2013/10/08 23:47:52]

icon_types_priority->icon_types

[michaelbai, 2013/10/10 05:51:43]

As element of the list could be a composition of icon_type, this name might
better than 'icon_types'

On 2013/10/08 23:47:52, sky wrote:

[sky, 2013/10/10 20:35:12]

I don't get this. Why do we need the ability to support *both* an ordered list
containing bitmasks and IconTypes. Can't we make it only an ordered list of
IconTypes? If you say no, why? What specific use case do you have that requires
a vector of bitmasks?

[michaelbai, 2013/10/10 22:39:58]

The use case is we want use favicon first if it is larger than normal size, if
not, the largest icon of touch_icon or precomposed_touch_icon would work, if
there is no touch_icon or precomposed_touch_icon, normal favicon will be used.

In this case, icon_types the vector should be
icon_types.push_back(FAVICON);
icon_types.push_back(TOUCH_ICON|PRECOMPOSED_TOUCH_ICON);


On 2013/10/10 20:35:12, sky wrote:

       int desired_size_in_dip,
       const std::vector<ui::ScaleFactor>& desired_scale_factors,
+      int threshold_for_next_icon_types,
       std::vector<chrome::FaviconBitmapResult>* bitmap_results);
 
   void GetFaviconForID(