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

Issue metadata

Status: Fixed
Closed: Mar 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression

Blocked on:
issue 568492

issue 471764

Sign in to add a comment

Issue 527709: CSS Columns not rendering positioned child in overlow:hidden containing block

Reported by, Sep 3 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36

Steps to reproduce the problem:
1. Create a CSS Columns Layout
2. Create an element with overflow:hidden (plus position: relative)
3. Absolutely position child inside element.
4. Element doesn't display

See above pen, works fine in IE, Firefox etc.

What is the expected behavior?
Absolute child should render as normal

What went wrong?
CSS Columns has never worked correctly in Chrome, but latest update (yesterday) has regressed it even further..

Did this work before? Yes 48 hours ago

Chrome version: 45.0.2454.85  Channel: stable
OS Version: OS X 10.10.5
Flash Version: Shockwave Flash 18.0 r0

Comment 1 by Deleted ...@, Sep 3 2015

I can confirm that setting overflow: hidden on an element inside a CSS Columns layout has unexpected behavior:

I use overflow: hidden in combination with display block on elements to align its content with f.e. an icon instead of resorting to padding and margin hacks.

The codepen solution worked in chrome 44 and all other modern browsers, but since the update to 45 it does not work anymore in chrome.

Comment 2 by, Sep 3 2015

I had a similar problem with sub-menus using CSS along the lines:

nav ul ul {
	display: none;
nav ul li:hover > ul {
	display: block;

These sub-menus suddenly stopped working with v45.

My fix may be rather specific, but for some reason the `<html>` element on the page had `position:relative` set.  Reset this back to the default `position:static` and sub-menus started working again in Chrome 45.

Comment 3 Deleted

Comment 4 Deleted

Comment 5 by Deleted ...@, Sep 3 2015

I can confirm the CSS Columns Absolute Overflow issue on v45 as well here: and I will add as you can see it only occurs after the 1st column. The 1st column renders as expected.

This issue occurs on v45 of both Mac & PC, v44 rendered correctly

Comment 6 by, Sep 4 2015

Labels: -OS-Mac OS-All M-46 Cr-Blink-CSS
Status: Assigned

Good Build:

45.0.2413.0    Base Position: 331302

Bad Build:

45.0.2414.0    Base Position: 331502


Able to repro this issue on Windows 7, 8.1, MAC (10.10.4) & Ubuntu Trusty (14.04) for the Google Chrome Stable Version - 45.0.2454.85

This is a regression issue broken in M45, below mentioned is the bisect info:



Suspecting - r195913

Review URL:

@mstensho/dsinclair/jchaffraix: Could you please have a look into the issue, and if it has nothing to do with your changes, please do assign it to the concerned owner.

Thank you.

Comment 7 by, Sep 4 2015

Comment #1 is about something else. No abspos there. Still a bug, though. Reported  bug 528179  for that.

The rest of this bug (abspos inside overflow:hidden) is already tracked by  bug 471764 , but since that bug is about a bunch of things, I'm not marking as dup, but rather adding a dependency.

Comment 8 by, Sep 4 2015

Labels: -Cr-Blink-CSS Cr-Blink-Layout-MultiCol

Comment 9 by, Sep 4 2015

Blocking: chromium:471764

Comment 10 by, Sep 4 2015

The test case for this bug is (comment #5). Attaching a simplified test case with pass condition.
475 bytes View Download

Comment 11 by, Sep 15 2015

Summary: CSS Columns not rendering positioned child in overlow:hidden containing block (was: CSS Columns Not Rendering Absolute Child in Overlow:Hidden Parent)
Abspos inside overflow:hidden is one thing, but when fixing this, we should also make sure that e.g. a relatively positioned child inside an overflow:hidden container gets painted.

Comment 12 by, Sep 15 2015

 Issue 531809  has been merged into this issue.

Comment 13 by, Sep 15 2015

 Issue 531528  has been merged into this issue.

Comment 14 by, Sep 16 2015

 Issue 532049  has been merged into this issue.

Comment 15 by, Sep 16 2015

Comment 16 by, Oct 1 2015

 Bug 531528  is no longer marked as duplicate. Different issue.

Comment 17 by, Oct 5 2015

 Issue 406349  has been merged into this issue.

Comment 18 by, Oct 6 2015

 Issue 523672  has been merged into this issue.

Comment 19 by, Oct 7 2015

 Issue 540541  has been merged into this issue.

Comment 20 by, Oct 9 2015

 Issue 541153  has been merged into this issue.

Comment 21 by, Oct 21 2015

 Issue 460222  has been merged into this issue.

Comment 22 by, Oct 28 2015

 Issue 548223  has been merged into this issue.

Comment 23 by, Nov 2 2015

 Issue 550204  has been merged into this issue.

Comment 24 by, Nov 12 2015

This is quite a serious bug for us, as we use columns heavily on some of our pages, e.g.

Comment 25 by, Nov 19 2015

 Issue 557515  has been merged into this issue.

Comment 26 by, Dec 1 2015

Any progress on this one? It has been identified for almost 3 month now.
Or maybe a workaround?

Comment 27 by, Dec 1 2015

I filed a band-aid patch a couple of weeks ago (due to the high number of duplicates here), but little progress.

There's no workaround that I know of, apart from not putting positioned objects inside containers with non-visible overflow. :(

Comment 28 by, Dec 1 2015

It's a shame there's no fix yet, even IE seems to be getting CSS-columns right...

Comment 29 by, Dec 8 2015

Serious bug for us, really don't want to rewrite our column grids with JavaScript as unfortunately we do need the positioning precision - been waiting for a few months now and it would be great to know if a fix was imminent

Comment 30 by, Dec 8 2015

I've pinged the review again.

Comment 31 by, Dec 8 2015

For reference, this is the review -
(Do not add comments there, it will only hinder progress)

Comment 32 by, Dec 14 2015

 Issue 453933  has been merged into this issue.

Comment 33 by, Dec 21 2015

 Issue 569050  has been merged into this issue.

Comment 34 by, Jan 27 2016

 Issue 530090  has been merged into this issue.

Comment 36 by, Jan 29 2016

 Issue 578097  has been merged into this issue.

Comment 37 by, Feb 3 2016

Confirming that this bug still exists only on chrome. It's been over four months. ... is anybody home? Hello?

Comment 38 by, Feb 4 2016

Believe it or not, but I'm actually working on it. It just requires a bunch of cleanup first.

Comment 39 by, Mar 17 2016

Is there any ETA for this fix? Our development is blocked by this bug. We don't want to go the js route to implement our grid layout.

Comment 40 by, Mar 18 2016

Blockedon: 568492

Comment 41 by, Mar 21 2016

Project Member
The following revision refers to this bug:

commit 8796ca1186b3ff3e3da105b3ee41f1698be01821
Author: mstensho <>
Date: Mon Mar 21 18:43:17 2016

Shift flowthread-to-visual coordinate space conversion one level up in the tree.

The conversion now takes place between the flow thread and its parent multicol
container, rather than between the flow thread and its children.

This is both conceptually more correct, and it also matches what
mapToVisibleRectInAncestorSpace() already does. Having all machineries do this
at the same place in the tree is what fixes the editing-specific  bug 596070 .

As for layer clipping  bug 527709 , it just so happens that we specify the flow
thread as ancestor in mapLocalToAncestor(), which is invoked via
localToAncestorPoint() from PaintLayerClipper::calculateClipRects().
PaintLayerClipper does its work *before* fragments have been collected and set
up for a given layer, so it doesn't want mapLocalToAncestor() or anyone to
change to the visual coordinate space.

BUG= 527709 , 596070

Review URL:

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


Comment 42 by, Mar 21 2016

Status: Fixed (was: Assigned)

Comment 43 by, Apr 12 2016

After upgrading Chrome recently (unfortunately I cannot provide the specific version we came from), we found this issue to repro again in our products. The pen provided in the bug ( actually does repro and it should have been fixed. We probably have a regression here.

Might be also related: However this last one involves only text and requires relative positioning.

Comment 44 by, Apr 12 2016

I suppose the tests regressed in Chrome 45, when the new multicol implementation was shipped. That's when this bug was reported.

This bug was fixed just a few weeks ago, so the fix is only available in Chrome 51 and later. Both tests render fine there, as far as I can tell. I can confirm that it looks broken in both Chrome 49 and Chrome 50.

Comment 45 by, Apr 12 2016

I see, so I need to wait for the new version on Chrome to be pushed out and check :)

Comment 46 by, Apr 12 2016

If you want to check right away, you can just download the dev channel of Chrome, since that's already on Chrome 51:

Comment 47 by, Apr 12 2016

I am now a proud owner of a dev-channel Chrome :) Verified in 51 and the issue got fixed! Kudos guys!

As a side note, I would like to contribute but I cannot find the place where I can get access to the codebase. I saw that you guys use Git, but could not find where I can fork the repository... in any case thanks!

Comment 48 by, Apr 12 2016

Comment 49 by, Apr 12 2016 tells you how to get the code. If you want to submit patches, there's some paperwork you need to go through first. Just send me an e-mail if you get stuck.

Comment 50 by, May 20 2016

 Issue 612794  has been merged into this issue.

Comment 51 by, Jun 30 2016

This issue still affects transformed descendents. A transformed element within an overflow hidden element within a multiple column context will not render.

See this Codepen test case: Does not work in Chrome Version 51.0.2704.106 (64-bit), yet works fine in Safari and Firefox.

We patiently awaited v51 assuming it would fix the this issue, not realizing transform was also problematic and would not be fixed :(

Comment 52 by, Jun 30 2016

#51 -
Please, create a new issue for that (you can comment here with the issue number).

Regarding verifying the fix, you could have installed the canary (it installs side by side) instead of assuming it would fix your use case.

Comment 53 by, Jun 30 2016

Also, positioned is not transformed... You misunderstood. :(

Comment 54 by, Jul 1 2016

I was in the same boat as #51 but noticed the fix wasn't going to work after checking Canary. I was able to get around the issue by using positioning (since it got fixed) instead of transforming the element.

Comment 55 by, Jul 8 2016

New bug filed:

#54 - I can't easily switch to positioning as my transform is a rotate.

Looks like overflow hidden and border radius is problematic too:

Our eyes that follow your cursor didn't render in Chrome due to 3 separate bugs all at once it seems.

Comment 56 Deleted

Sign in to add a comment