"Unable to reproduce the issue on reported version 63.0.3218.0, Latest Stable 61.0.3163.79 using Mac 10.12.1, Windows 7 and Ubuntu 14.04.
 
Could you please re-try the scenario by creating a new profile without any extensions or apps.

Please follow below steps to create a New profile
(i)Launch chrome>>Press Alt+E>>Settings)
(ii)Under the section headed People, Click on link Manage other people>>Add person 
2. Welcome page opens>> Now hit the given link provided in the original comment

If the issue still persist please provide your observation that would help us in further triaging of the issue "

Before reposting this issue I downloaded fresh version of Canary, so User Profile was new, but I've tested it now with your instruction and can confirm that the issue persists.

Here are 2 videos:
1. Chrome with borderRadius problem -
 https://www.dropbox.com/s/pcxr9u2tbritlm3/Chrome_borderRadius_bug.mov
2. FireFox without problem (just to compare) - https://www.dropbox.com/s/5egmf6pzqt9bnhe/FireFox_borderRadius.mov?dl=0

And screenshot - http://vns.ru/screenshots/20170918194206.png

Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

*reposting = reporting

One more finding:
- videos above are recorded on OSX El Capitan (10.11.6)
- on OSX Sierra (10.12.5) bottom corners are never rounded even before/after animation they are square which is even worse.

One more related bug: you can disable animation at all (comment lines with setTimeout in code snippet), then on MacBook Pro screen bottom corners are NOT rounded at all, but if we drag window to external display (in my case it's Dell UP2716D) then corners are rounded - without resizing the page or any manipulation, just dragging window. I can record video if you can't reproduce it.

Moving to paint because it seems more likely that this is a bug in that area.

The local/external display differences referenced in comment #c8 are due to differences in Chrome's behavior on HighDPI and regular devices. When an element is transitioned it gets a compositing layer for animation and you are seeing a bug in border radius on composited iframes.

Clearly we have not fixed this case, despite fixing a bunch of others.

Note the transition case reproduces on all platforms.

 

Just requires an iframe with scrolling content inside the border radius element.

Deleted: cr765985.html 196 bytes

cr765985.html 196 bytes View Download

Deleted: cr765985-iframe.html 252 bytes

cr765985-iframe.html 252 bytes View Download

Turns out you don't even need scrolling. Just compositing the sub-frame breaks it.

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

commit 20c3c4178f0a1f0847fff1df62b3704fb690108f
Author: Xianzhu Wang <wangxianzhu@chromium.org>
Date: Wed Dec 06 01:16:08 2017

[SPv175+] Generate InnerBorderRadiusClip for IFrames with border radius

IFrames can have border-radius applying to the contents.
Now generate InnerBorderRadiusClip property node for such IFrames.

Bug:  765985 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I42587e4c046728e15a19097c25466e229b6c6da8
Reviewed-on: https://chromium-review.googlesource.com/807335
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521935}
[modify] https://crrev.com/20c3c4178f0a1f0847fff1df62b3704fb690108f/third_party/WebKit/Source/core/paint/PaintPropertyTreeBuilder.cpp
[modify] https://crrev.com/20c3c4178f0a1f0847fff1df62b3704fb690108f/third_party/WebKit/Source/core/paint/PaintPropertyTreeBuilderTest.cpp
[modify] https://crrev.com/20c3c4178f0a1f0847fff1df62b3704fb690108f/third_party/WebKit/Source/core/paint/RarePaintData.cpp

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

commit 88986f832c463a210324d7d9cf9b5213f7b69f63
Author: Stephen Chenney <schenney@chromium.org>
Date: Thu Dec 07 22:26:15 2017

[PE] Apply border radius to composited IFrame contents

Chromium supports border radius on IFrames but does not apply that
border radius when the IFrame content is composited. This patch fixes
the issue.

Embedded objects with border radius are now be detected as
having composited children, leading to child containment layers
and clip mask layers for composited content. Painting code is modified
to collect rounded clip rects for embedded content and to use those
clips when painting the mask.

The code is somewhat complicated by the need to avoid using the clips
when painting any phase other than the clip mask, because we would then
clip out the border of the frame painted in the foreground phase.

R=chrishtr@chromium.org
BUG= 765985 

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I5af847e68aa2d3ee8e76dbbd25eef087dbac4060
Reviewed-on: https://chromium-review.googlesource.com/772779
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Reviewed-by: Tien-Ren Chen <trchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522577}
[modify] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/LayoutTests/FlagExpectations/enable-slimming-paint-v2
[modify] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/LayoutTests/compositing/overflow/border-radius-composited-subframe.html
[add] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/LayoutTests/compositing/overflow/resources/composited-subframe-2.html
[add] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/LayoutTests/fast/borders/border-radius-iframe-expected.html
[add] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/LayoutTests/fast/borders/border-radius-iframe.html
[add] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/LayoutTests/fast/borders/resources/subframe.html
[add] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/LayoutTests/platform/mac/compositing/overflow/border-radius-composited-subframe-expected.png
[add] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/LayoutTests/platform/mac/compositing/overflow/border-radius-composited-subframe-expected.txt
[add] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/LayoutTests/platform/win/compositing/overflow/border-radius-composited-subframe-expected.png
[add] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/LayoutTests/platform/win/compositing/overflow/border-radius-composited-subframe-expected.txt
[modify] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/Source/core/paint/LayerClipRecorder.cpp
[modify] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/Source/core/paint/PaintLayerClipper.cpp
[modify] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp
[modify] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/Source/core/paint/PaintLayerPainter.h
[modify] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.cpp
[modify] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/Source/core/paint/compositing/CompositingRequirementsUpdater.cpp
[modify] https://crrev.com/88986f832c463a210324d7d9cf9b5213f7b69f63/third_party/WebKit/Source/core/paint/compositing/PaintLayerCompositor.cpp

wangxianzhu@, are we safe to leave this in? From the other reviews and bugs it seems you have fixed the issue leading to potential revert.

Yes, it's safe. There was just a small bug in PaintLayerPainter::NeedsToClip() which was changed in my CL the small bug was fixed by the way.

Verified fixed for M-65

 Issue 813668  has been merged into this issue.