You want all bubbles/dialogs everywhere to have 2 DIP corners?  Note that at 1x, 2 DIP looks pretty square.

There is

int BubbleBorder::GetBorderCornerRadius() const {
  return UseMd() ? 3 : images_->corner_radius;
}


I guess we change that 3 to a 2... seems to work.

That's from r419203 where drawing switched from raster to vector. (otherwise changing this would be hard!).  Issue 635170  has the old spec that was being implemented. That spec also has 2px, so I don't know why it's a 3 right now..

As long as the omnibox @1x is 2dp then the answer is yes to comment #1.

> As long as the omnibox @1x is 2dp then the answer is yes to comment #1.

If only it was that simple...

On Mac, 

https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/location_bar/autocomplete_text_field_cell.mm?type=cs&q=kCornerRadius&sq=package:chromium&l=32

says

  // Matches the clipping radius of |GradientButtonCell|.
  const CGFloat kCornerRadius = 3.0;


and GradientButtonCell has


  // TODO(viettrungluu): clean this up.
  // (Private)
  - (void)getDrawParamsForFrame:(NSRect)cellFrame ... {
    ..
    CGFloat cornerRadius = 2;
    if (![self isMaterialDesignButtonType]) {
      cornerRadius = 3;

<-- https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/gradient_button_cell.mm?type=cs&q=getDrawParamsForFrame&sq=package:chromium&l=490

But that logic isn't repeated for the omnnibox.

:|


As for the omnibox stroke (on Mac), it's even weirder. It is inset half a pixel (i.e. 0.5 DIP or 0.25 DIP in hidpi). The stroke width is one pixel, but it is increased by a whole pixel when the omnibox has focus.  But this has the effect of drawing over 3 pixels in HiDPI (see attached), since it's a 1 DIP line that's been offset by 0.25 DIP.

Then if it's not an incognito window, it's inset an additional whole pixel (so the omnibox shrinks on mac when it gets focus).

This all put together has a pretty bizarre effect on that "corner radius = 3". (The bezier curve that comes out is garbage basically). But it will make aligning bubbles super annoying.

I'm not sure how much of that is intentional, or whether toolkit-views browsers have the same nightmare to deal with..

Anyway, I'll leave this Issue for the corner radius and follow-up with alignment on Mac in  Issue 761701 .

Deleted: Screen Shot 2017-09-04 at 15.30.56.png 3.8 KB

	Screen Shot 2017-09-04 at 15.30.56.png 3.8 KB View Download

Views stuff basically makes sense.  I don't remember exactly what the radius is offhand, but it's not weird like you describe.

Windows screengrabs for https://chromium-review.googlesource.com/c/chromium/src/+/647773

(see https://bugs.chromium.org/p/chromium/issues/detail?id=761701#c1 for Mac screengrabs)

Deleted: win_3px_BEFORE.png 4.3 KB

	win_3px_BEFORE.png 4.3 KB View Download

Deleted: win_2px_FIXED.png 3.9 KB

	win_2px_FIXED.png 3.9 KB View Download

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

commit bd5b0a0372ff4d793715cda5269b9d5c7f806b2e
Author: Trent Apted <tapted@chromium.org>
Date: Thu Sep 07 00:36:55 2017

Harmony bubble corner radius. Was: 3. Now: 2.

This matches the spec, and the omnibox corner radius.

Bug:  760429 
Change-Id: I0a1b401c4dbcbbf10599c42531e26d081c3f4a32
Reviewed-on: https://chromium-review.googlesource.com/647773
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#500159}
[modify] https://crrev.com/bd5b0a0372ff4d793715cda5269b9d5c7f806b2e/ui/views/bubble/bubble_border.cc

this is fixed.  Issue 761701  is still open to do something about the Mac omnibox's quirky focus ring.

Thank you!

The NextAction date has arrived: 2017-09-29