New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 783602 link

Starred by 1 user
Status: Fixed
Owner:
schenney@chromium.org
Closed: Dec 2017
Cc:
█ vamshi.k...@techmahindra.com
vmp...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

A container with a border-radius and overflow "hidden" does not hide the nested elements

Reported by kyber...@gmail.com, Nov 10 2017 
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.104 Safari/537.36

Steps to reproduce the problem:
Start html:

<html>
    <head>
        <style>
            #wrapper {
                position: absolute;
                overflow: hidden;
                border-radius: 50%;
                height: 300px;
                width: 300px;
                background: red;
            }

            #inner {
                position: absolute; 
                background: black; 
                height: 50%; 
                width: 100%;
            }
        </style>
    </head>
    <body>
        <div id = "transform" style = "transform: rotateY(0deg);"></div>

        <div id = "wrapper">
            <div id = "inner"></div>
        </div>
    </body>
</html>

What is the expected behavior?
Should be a circle divided into two halves, one in black, the other in red.

What went wrong?
As a result, the nested element #inner was not trim by the parent #wrapper

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 59.0.3071.104  Channel: n/a
OS Version: 
Flash Version: Shockwave Flash 27.0 r0

If the block #transform is placed after the block #wrapper, everything will be as expected.
If all the styles are rendered in a separate file, everything will be as expected.

Comment 1 by mikelawther@chromium.org, Nov 12 2017

Components: -Blink>CSS Blink>Paint
Labels: Needs-Bisect
clicky test here: https://jsfiddle.net/6vsuLraa/

Tested on Windows 10.

Chrome Stable 62.0.3202.89 (Official Build) (64-bit) (cohort: 62_89_win): BAD
Chrome Canary 64.0.3266.0 (Official Build) canary (32-bit) (cohort: Clang-32): GOOD


Requesting bisect to find where this was fixed to determine whether a merge is needed.

Comment 2 by vamshi.k...@techmahindra.com, Nov 13 2017

Cc: vamshi.k...@techmahindra.com
Labels: -Pri-2 -Needs-Bisect hasbisect-per-revision Triaged-ET M-62 OS-Mac OS-Windows Pri-1
Owner: schenney@chromium.org
Status: Assigned (was: Unconfirmed)
"Able to reproduce the issue on reported chrome version 59.0.3071.104 and on the latest stable 62.0.3202.94 using ubuntu 14.04, Windows 10 and Mac 10.12.6. As the issue is not seen in latest dev 64.0.3266.0, hence providing reverse bisect.

Manual Reverse Bisect info:
--------------------------------------
Good Build:  63.0.3239.0 - Revision(508578)
Bad Build : 63.0.3238.0 - Revision(508208) 

You are probably looking for a change made after 508328 (known good), but no later than 508329 (first known bad).

CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/6c83d8de501b554f57128b285c5f91275b85ab08..8ff2371257ac4f24d77da4a62569840a53c49b47

Probably fixed by :https://chromium-review.googlesource.com/699170

@schenney:Could you please confirm if its safe to merge to M-62 in case we have stable refresh?
"

Comment 3 by schenney@chromium.org, Nov 13 2017

Labels: -Pri-1 Pri-2
The is discussion about the fix for this. It caused a significant performance regression and the fix for that performance regression would be the one to merge back. Given we are still deciding on an M-63 merge, it seems unlikely we'll do M-62.

It is also the case that this has been broken for a long time and has a simple workaround: remove the inline transform and put it in a style block. So reducing the priority.

Comment 5 by schenney@chromium.org, Dec 4 2017

Status: Fixed (was: Assigned)
Fixed on trunk by a63dd55906d02fcac050c36b289e29d3f7a95453
►

Sign in to add a comment