I can only reproduce this when I start trying non 100% scale factors - is that consistent with what you're seeing? Or do you also see this at 100%?

Ah, that's why. I was using my laptop yesterday which uses non-100%. It's not reproing @100% on my desktop machine.

I guess this is more of a general HDPI bug? Adding in Bret in case he has any specific thoughts here.

Any chance that this is related to RoundRectInkDropMask using float parameters and possibly accepts fractions of a DPI?

Possibly? I think this is definitely not a BubbleIconView issue as if you try --force-device-scale-factor=1.1, this also happens with the ToolbarButton views. So may be an ink drop issue. This also is reproducible in non-touchable (i.e. no flag passed to --top-chrome-md). I think ImageButtons are affected too (e.g. the 'x' button on infobars).

Peter, if you or someone on the wider Views team could take this it would be much appreciated!

Thanks that makes sense, and makes it less urgent as a non-regression. I've put it on my backlog hotlist and will hopefully get to it at some hdpi push. Thanks :)

bettes@ FYI this is the bug that prevents me from doing a 3dp Touchable border. When it's fixed I owe you a 3dp border.

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

commit af504d01b70d3331ab1008517fd3a48cb5fdfa04
Author: Peter Boström <pbos@chromium.org>
Date: Wed May 23 20:20:48 2018

Add location-bar padding for newer material

Adds 2dp of interior padding for Refresh and 3dp for Touchable variants
which effectively adds a border to newer material layouts. This
insetting ends up with 24x24dp (and fixes 24x26dp) location-bar
page-action icons which fixes the inkdrop size. Prior to this the
24x24dp icons were upscaled to 26dp to match the location-bar interior
height.

The corresponding LOCATION_BAR_ICON_INTERIOR_PADDING value is updated
for Touchable to provide a square location-bar icon, but the existing
value results in a square for the updated interior padding (which is why
this fixes the 24x26dp oval inkshape bug).

By using even LOCATION_BAR_ELEMENT_PADDING this also accidentally fixes
a tangental bug where these icons bob up and down on hover in 150% HiDPI
modes. This has not yet been root caused but is seen as a nice bonus. It
is not fixed for 125%, so won't mark as fixed.

Corresponding screenshots of Touchable and Refresh combinations have
been approved by bettes@.

Bug: chromium:839148,  chromium:845200 
Change-Id: I68482d16decb5f8102c8cd6317ba3b0c1587e652
Reviewed-on: https://chromium-review.googlesource.com/1070367
Commit-Queue: Peter Boström <pbos@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561233}
[modify] https://crrev.com/af504d01b70d3331ab1008517fd3a48cb5fdfa04/chrome/browser/ui/layout_constants.cc
[modify] https://crrev.com/af504d01b70d3331ab1008517fd3a48cb5fdfa04/chrome/browser/ui/views/location_bar/location_bar_view.cc

Upping priority.

Triage: Upgrading to P1 - Flicker or movement now meets the P1 bar.

Load balancing to bsep@

This isn't a Refresh-related regression, see comment #4. I confirmed it reproduces with Refresh off.

Triage: Since this isn't a refresh related regression and the impact is small, this no longer meets the P1 bar.

**UI mass Triage**

We were unable to find repro steps for this bug. If you have more data to
reproduce this bug or have clear repro steps, please reopen or file a new issue.

Thanks!

This still repros on my Surface Pro, use a device with say 125% DPI and hover buttons.