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

ui/gfx/paint_vector_icon.cc

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "ui/gfx/paint_vector_icon.h"
 
 #include <map>
 #include <tuple>
 
 #include "base/i18n/rtl.h"
@@ skipping 387 matching lines @@
 
 ImageSkia CreateVectorIcon(VectorIconId id, size_t dip_size, SkColor color) {
   return CreateVectorIconWithBadge(id, dip_size, color,
                                    VectorIconId::VECTOR_ICON_NONE);
 }
 
 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,
                                      size_t dip_size,
                                      SkColor color) {
   return ImageSkia(
       new VectorIconSource(source, dip_size, color),
       gfx::Size(static_cast<int>(dip_size), static_cast<int>(dip_size)));
 }
 
 }  // namespace gfx