Fix padding in location bar bubbles to match specs on bug.

ui/gfx/paint_vector_icon.cc

Index: ui/gfx/paint_vector_icon.cc
diff --git a/ui/gfx/paint_vector_icon.cc b/ui/gfx/paint_vector_icon.cc
index 6091897f811fc773251f92deea66959cd3b0014f..087d0ee31fe093820c8f115d438fd825708316eb 100644
--- a/ui/gfx/paint_vector_icon.cc
+++ b/ui/gfx/paint_vector_icon.cc
@@ -405,7 +405,10 @@ ImageSkia CreateVectorIconWithBadge(VectorIconId id,
                                     size_t dip_size,
                                     SkColor color,
                                     VectorIconId badge_id) {
-  return g_icon_cache.Get().GetOrCreateIcon(id, dip_size, color, badge_id);
+  return (id == VectorIconId::VECTOR_ICON_NONE)

[Evan Stade, 2016/03/30 21:44:13]

After thinking about this more, the thing that worries me is that now the
returned image doesn't have the same dimensions (dip_size x dip_size). I'd be
concerned that things like ImageView might need a relayout when the actual image
is set (SetImage calls PreferredSizeChanged() but most containers will ignore
that), or that VECTOR_ICON_NONE images might validly be used as a placeholder to
reserve space for a real image. I wonder if it's easy to create an empty
gfx::ImageSkia of a specified size? Does oshima@ know?

[Peter Kasting, 2016/03/30 21:53:23]

Why do you say most containers will ignore PreferredSizeChanged()? 
View::PreferredSizeChanged() calls InvalidateLayout().  Unless you override
PreferredSizeChanged() to specifically not do that (which no one does; we have 2
overrides in the codebase and both call the base class method), that will force
a relayout.

As for using VECTOR_ICON_NONE with a specific dip_size to reserve space for
something, this seems unlikely, since in general "reserving space" is not a
pattern we use in views.  When something changes, we normally just relayout. 
And conceptually, I can't think of a case where I'd have an empty spot but want
to hold a gap there for some possible later object to fill.  We want empty
sections of the UI to collapse during layout, so that e.g. the omnibox takes all
the available space in the address bar, or the tab content takes all the
available space in the tab, or whatever similar concept you may be dealing with.

I think we're safe here.

+             ? gfx::ImageSkia()
+             : g_icon_cache.Get().GetOrCreateIcon(id, dip_size, color,
+                                                  badge_id);
 }
 
 ImageSkia CreateVectorIconFromSource(const std::string& source,