Move IconURLs method from WebFrame to WebLocalFrame

components/favicon/content/favicon_url_util.cc

Index: components/favicon/content/favicon_url_util.cc
diff --git a/components/favicon/content/favicon_url_util.cc b/components/favicon/content/favicon_url_util.cc
index c77ff8b7808453325ec5446d51b8cb42206297e7..a0bb2065a902c25212dacc2186154dbd8e33c36f 100644
--- a/components/favicon/content/favicon_url_util.cc
+++ b/components/favicon/content/favicon_url_util.cc
@@ -25,9 +25,10 @@ favicon_base::IconType IconTypeFromContentIconType(
       return favicon_base::TOUCH_PRECOMPOSED_ICON;
     case content::FaviconURL::INVALID_ICON:
       return favicon_base::INVALID_ICON;
+    default:

[dcheng, 2017/06/06 20:01:30]

Nit: prefer to keep this out of the switch statement, so the compiler can warn
on new (unhandled) values.

[Łukasz Anforowicz, 2017/06/06 20:55:00]

Thanks for bringing this up.  I moved this in, because the compiler started
complaining about MAX_BIT_MASK field being unhandled.  Hmmm... I think I got
confused here - I think that content::FaviconURL::IconType is NOT a bitmask and
should be rewritten to avoid using the shift operator when defining enum values
(OTOH blink::WebIconURL::Type is indeed a bitmask).

So - in the next patchset I changed content::FaviconURL::IconType so that:
- It uses consecutive values (0,1,2,3,4... rather than 0,1,2,4,8,...)
- It is a class enum that uses kModernChromiumStyleNaming (this is not
technically required, but let's me find and inspect all uses to make sure nobody
uses this enum as a bitmask).

Done (I think).

+      NOTREACHED();
+      return favicon_base::INVALID_ICON;
   }
-  NOTREACHED();
-  return favicon_base::INVALID_ICON;
 }
 
 }  // namespace