I suspect some sort of blink or other rendering issue here, but it pays to start looking at the dialog itself as a first step.

I couldn't repro this on ToT.

sdantuluri@ does this still happen in latest TOT?

I can still see the issue on TOT build 8165.0.0 / 51.0.2701.0 dev-channel link

Also repro'd on TOT 8178.0.0 / 51.0.2701.0 dev-channel link

Is that specific to link? 
I still can't repro on ToT (see snapshots):
- 51.0.2701.0 / 8180.0.0
- 52.0.2706.0 / 8180.0.0

How do you trigger this?

Deleted: Screenshot 2016-04-11 at 1.19.35 PM.png 144 KB

	Screenshot 2016-04-11 at 1.19.35 PM.png 144 KB View Download

Deleted: Screenshot 2016-04-11 at 1.21.58 PM.png 149 KB

	Screenshot 2016-04-11 at 1.21.58 PM.png 149 KB View Download

I have seen this issue only on Link device.

Not reproduced on other devices

I'll test on a link.

I can repro on link. It is happens when this CSS style is applied: https://code.google.com/p/chromium/codesearch#chromium/src/ui/webui/resources/css/apps/common.css&q=blue-button&sq=package:chromium&l=72&dr=C

Probably a blink issue.

Do you happen to know the last good version?

Bad : 8041.0.0 / 51.0.2672.0
Good: 8038.0.0 / 50.0.2657.0

Good: 7978.42.0 / 50.0.2661.64

bisecting ...

Bisect ended. Showing this CL: https://codereview.chromium.org/1756763004 is the culprit.

Assigning to the owner of that CL.

 Issue 602743  has been merged into this issue.

Issue also seen on new user Welcome screens. Attached screenshots

Deleted: Screenshot 2016-04-13 at 3.15.50 PM.png 4.1 MB

	Screenshot 2016-04-13 at 3.15.50 PM.png 4.1 MB View Download

Deleted: Screenshot 2016-04-13 at 3.16.04 PM.png 4.0 MB

	Screenshot 2016-04-13 at 3.16.04 PM.png 4.0 MB View Download

 Issue 597185  has been merged into this issue.

Sorry for not getting at this yet. I'll take a look at this first thing tomorrow.

Anything special with Link devices? Do they have hidpi screens?

Thanks for the useful link to common.css, but do anyone know where the html and js code are for the affected screens?

Here's the js file: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/feedback/js/feedback.js&q=f:%20feedback.js&sq=package:chromium&type=cs&l=1

Here's the html file: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/feedback/html/default.html&sq=package:chromium&type=cs&q=f:%20chrome/browser/resources/feedback/html/default.html&l=1

Re #20 yes. Link is the first-gen Pixel. It has a 2x screen.

Do we have any update on this bug since I am still able to reproduce the issue on Windows 10(4K resolution with 200% scaling) and as stated above on ChromeOS(Link machine) with Chrome versions 	51.0.2704.19 and 51.0.2704.15 respectively , Since this is marked as Beta blocker please get the fix landed soon.

Any update here? We're cutting M51 Beta RC tomorrow, Wednesday @ 5:00 PM PST.

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

commit ecead9a073907d4a2ba8b98527c9cb22125d6fa8
Author: davve <davve@opera.com>
Date: Wed Apr 20 09:06:22 2016

Compensate for source scaling in hidpi mode

In crrev.com/379801 scaling of hidpi nine piece image grids was
changed from using the real image size to using the "layout'ed" image
size (i.e. image size compensated by image scale factor) since that is
what Image::imageSize() returns. Instead the computed source rect was
scaled afterwards, right before drawing.

If GraphicsContext.drawTiledImage() is called with (stretch, stretch)
as tile rules, it ignores the passed scale factor and computes the
scale factor between source and destination itself. However, if one
rule is stretch and the other one repeat, or if both are repeat, the
tile scale factor is used when drawing and the relation between the
sizes of source and dest ignored.

What was missing from crrev.com/379801 was to compensate for the image
scale factor by adjusting tileScale. That meant that the (stretch,
stretch) worked fine but as soon as one repeat was specified, the
scale factor was wrong.

BUG= 601544 

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

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

[add] https://crrev.com/ecead9a073907d4a2ba8b98527c9cb22125d6fa8/third_party/WebKit/LayoutTests/fast/hidpi/image-set-border-image-button-expected.html
[add] https://crrev.com/ecead9a073907d4a2ba8b98527c9cb22125d6fa8/third_party/WebKit/LayoutTests/fast/hidpi/image-set-border-image-button.html
[add] https://crrev.com/ecead9a073907d4a2ba8b98527c9cb22125d6fa8/third_party/WebKit/LayoutTests/fast/hidpi/resources/black-blue-outline-12-px-square.png
[add] https://crrev.com/ecead9a073907d4a2ba8b98527c9cb22125d6fa8/third_party/WebKit/LayoutTests/fast/hidpi/resources/black-blue-outline-6-px-square.png
[modify] https://crrev.com/ecead9a073907d4a2ba8b98527c9cb22125d6fa8/third_party/WebKit/Source/core/paint/NinePieceImageGrid.cpp
[modify] https://crrev.com/ecead9a073907d4a2ba8b98527c9cb22125d6fa8/third_party/WebKit/Source/core/paint/NinePieceImageGrid.h
[modify] https://crrev.com/ecead9a073907d4a2ba8b98527c9cb22125d6fa8/third_party/WebKit/Source/core/paint/NinePieceImageGridTest.cpp
[modify] https://crrev.com/ecead9a073907d4a2ba8b98527c9cb22125d6fa8/third_party/WebKit/Source/core/paint/NinePieceImagePainter.cpp

Approved merge to M51 branch 2704 based on email conversation. Please merge ASAP as we're cutting M51 Beta candidate @ 5:00 PM PST today.

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

commit e4c8a71cfd74d07cd9ae15f7be899f24ded225e1
Author: pdr@chromium.org <pdr@chromium.org>
Date: Wed Apr 20 23:02:21 2016

Compensate for source scaling in hidpi mode

In crrev.com/379801 scaling of hidpi nine piece image grids was
changed from using the real image size to using the "layout'ed" image
size (i.e. image size compensated by image scale factor) since that is
what Image::imageSize() returns. Instead the computed source rect was
scaled afterwards, right before drawing.

If GraphicsContext.drawTiledImage() is called with (stretch, stretch)
as tile rules, it ignores the passed scale factor and computes the
scale factor between source and destination itself. However, if one
rule is stretch and the other one repeat, or if both are repeat, the
tile scale factor is used when drawing and the relation between the
sizes of source and dest ignored.

What was missing from crrev.com/379801 was to compensate for the image
scale factor by adjusting tileScale. That meant that the (stretch,
stretch) worked fine but as soon as one repeat was specified, the
scale factor was wrong.

BUG= 601544 

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

Cr-Commit-Position: refs/heads/master@{#388451}
(cherry picked from commit ecead9a073907d4a2ba8b98527c9cb22125d6fa8)

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

Cr-Commit-Position: refs/branch-heads/2704@{#154}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[add] https://crrev.com/e4c8a71cfd74d07cd9ae15f7be899f24ded225e1/third_party/WebKit/LayoutTests/fast/hidpi/image-set-border-image-button-expected.html
[add] https://crrev.com/e4c8a71cfd74d07cd9ae15f7be899f24ded225e1/third_party/WebKit/LayoutTests/fast/hidpi/image-set-border-image-button.html
[add] https://crrev.com/e4c8a71cfd74d07cd9ae15f7be899f24ded225e1/third_party/WebKit/LayoutTests/fast/hidpi/resources/black-blue-outline-12-px-square.png
[add] https://crrev.com/e4c8a71cfd74d07cd9ae15f7be899f24ded225e1/third_party/WebKit/LayoutTests/fast/hidpi/resources/black-blue-outline-6-px-square.png
[modify] https://crrev.com/e4c8a71cfd74d07cd9ae15f7be899f24ded225e1/third_party/WebKit/Source/core/paint/NinePieceImageGrid.cpp
[modify] https://crrev.com/e4c8a71cfd74d07cd9ae15f7be899f24ded225e1/third_party/WebKit/Source/core/paint/NinePieceImageGrid.h
[modify] https://crrev.com/e4c8a71cfd74d07cd9ae15f7be899f24ded225e1/third_party/WebKit/Source/core/paint/NinePieceImageGridTest.cpp
[modify] https://crrev.com/e4c8a71cfd74d07cd9ae15f7be899f24ded225e1/third_party/WebKit/Source/core/paint/NinePieceImagePainter.cpp

@davve and @fs, the aforementioned email conversation was because the release managers don't know you and asked me whether we should merge this. They now know you're both superstar engineers and can make these merge decisions in the future :)

I'm going to go ahead and merge this into M51. The fix is clean and, in the unlikely case that this causes a regression, we still do have some time to pull this back out.

Thanks for merging this Philip! Please let me know if I can be of more assistance.

Resolving since the fix should be present on both M51 and trunk now.

Verified on ChromeOS TOT (8282.0.0, 52.0.2724.0) and (8172.25.0, 51.0.2704.37)