We could also start from the icon width instead of zero, as long as we didn't do so by clamping (which would cause a pause before the animation started).  I'm on the fence about which is better, but starting from the icon width would be more consistent with how icons appear when they _aren't_ animating a bubble, in that they just pop into view.

If we do this, we could probably avoid problem (2) by ensuring that the width we start from is (icon width) + (leading and trailing padding).

I think it is OK to start at zero width with clipping and padding the icon. I think it will look fractionally smoother. However I would also suggest making it not stoppable with a click until the total width grows past the (icon width) + (leading and trailing padding).
I am currently experimenting with stopping animation when the icon's right edge crosses the right bubble's boundary in shrinking phase and it looks quite nice. I will post the slow-motion of that soon.

Maybe if a user clicks the bubble before it's as large as the icon it should snap up to the icon size.

#3, yes, this is what I meant, register the click but progress or better yet snap (the difference is not going to be noticeable at normal speed) to the icon size.
Attached is a slow motion exploration how MD animation could look like.

Deleted: bubble-new-md.ogv 538 KB

bubble-new-md.ogv 538 KB Download

This animation looks pretty good.  Just two things:

(1) The non-MD case, as you noted over IM, looks like it gets clamped at the beginning, resulting in sticking at a slightly odd size.  I'd like to remove that clamp so that this looks just like the MD start.
(2) The MD case clips the icon a little at the very end, whereas the non-MD case doesn't.  The latter looks better.  It seems like maybe what we'd need to do is make the bubble outline/background vanish a few pixels sooner, like when the icon begins to cross into what would normally be the trailing padding area?

#5, I think I have managed to get both those as well as the RTL case (the icon was mirrored but we were not properly flipping which edge gets exposed first). See if you spot any troubles worth fixing.
For comment #3 I have experimented a bit and I thought it makes sense to bypass the animation and snap directly to the end state. The dropdown has all the information and if you somehow manage to click the animation in its first 10 milliseconds then there is probably no expectation to see the animation. It looked simpler and more consistent to me.

Deleted: bubble-new-non-md-1.ogv 830 KB

bubble-new-non-md-1.ogv 830 KB Download

Deleted: bubble-new-md-1.ogv 1.1 MB

bubble-new-md-1.ogv 1.1 MB Download

Deleted: bubble-new-rtl-md-1.ogv 727 KB

bubble-new-rtl-md-1.ogv 727 KB Download

This is continuing to look better.  The issues below are all minor except for the jerking in MD.

In the non-MD case there is some sort of flicker right as the bubble disappears at the end.  Could this be some kind of rounding/precision issue where if the animation happens to hit the right values we might hide, re-show, then hide the bubble again?  Is this just a video artifact?

This case also shows only the left side of the bubble as it begins to animate, unlike the MD case where we show a min-width closed bubble first.  If possible that would be nice to do for non-MD, I wouldn't block on it though.

In the MD case, the animation seems to be hitching oddly.  Again, is this real, or a video artifact?

There's also a slight blip at the end where the animation looks complete for a while, but then the text left of the icon gets un-clipped by a few pixels.  Would be nice to have animated all the way to this state instead of apparently jumping to it after the animation finishes.

Oh yeah.  The MD bubble also seems to have tons more trailing padding than leading padding.  This isn't the case with non-MD.  It would be good to reduce this to match the leading padding.

This may be a dupe of part of  bug 586423 .

Yes, looking at the code making kIconLabelViewTrailingPadding less for MD modes should do that. It will not deal with all of the  bug 586423  but will fix the extra large trailing padding.

Yes, I think the strange things you mentioned are video frame timing artifacts. I have slowed the animation even more and I don't see most of them. The text in the omnibox does have some layout that only gets exposed with an additional repaint but this is not a regression. It is because when background is hidden at the end of the animation the icon bubble is sized to just the image. We can track it separately.
Definitely wouldn't block on non-MD visuals at the very very beginning - those are probably invisible because the first animation frame should be past that point. And non-MD is going away. I will push a CL soon.

Draft CL at https://codereview.chromium.org/1763713004/.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a2a4fab1693d6985dda4de9e91825fd667f07598

commit a2a4fab1693d6985dda4de9e91825fd667f07598
Author: varkha <varkha@chromium.org>
Date: Fri Mar 11 21:12:24 2016

Adjusts content bubble animation with respect to icon size

This CL corrects several issues with the icon bubble animation:
1. The bubble is not clipping its children, so the image draws outside the bubble bounds. This is MD-specific.
2. The image is being centered at the bubble center when the size is too low, instead of always being positioned based on the leading edge of the bubble, so it doesn't "slide in" correctly shifting during the initial portion of the animation.
3. The animation "closes" down to zero width (MD) or smaller than necessary width (non-MD) and then snaps the image back into place; it should animate down to become just large enough to show the image.
4. Removes the clamp in non-MD size that prevents animation from starting at zero.
5. Avoids clipping icon at the end of the animation (MD) by hiding the border even before the animation ends.
6. Reduces padding at the end of the MD version of the text label.
7. Corrects RTL layout by showing trailing edge of the icon first.

BUG= 591411 

Review URL: https://codereview.chromium.org/1763713004

Cr-Commit-Position: refs/heads/master@{#380729}

[modify] https://crrev.com/a2a4fab1693d6985dda4de9e91825fd667f07598/chrome/browser/ui/layout_constants.cc
[modify] https://crrev.com/a2a4fab1693d6985dda4de9e91825fd667f07598/chrome/browser/ui/views/location_bar/content_setting_image_view.cc
[modify] https://crrev.com/a2a4fab1693d6985dda4de9e91825fd667f07598/chrome/browser/ui/views/location_bar/content_setting_image_view.h
[modify] https://crrev.com/a2a4fab1693d6985dda4de9e91825fd667f07598/chrome/browser/ui/views/location_bar/icon_label_bubble_view.cc
[modify] https://crrev.com/a2a4fab1693d6985dda4de9e91825fd667f07598/chrome/browser/ui/views/location_bar/icon_label_bubble_view.h
[add] https://crrev.com/a2a4fab1693d6985dda4de9e91825fd667f07598/chrome/browser/ui/views/location_bar/icon_label_bubble_view_unittest.cc
[modify] https://crrev.com/a2a4fab1693d6985dda4de9e91825fd667f07598/chrome/chrome_tests_unit.gypi