Issue metadata
Sign in to add a comment
|
Issue 527709: CSS Columns not rendering positioned child in overlow:hidden containing block
Reported by
thejames...@gmail.com,
Sep 3 2015
|
||||||||||||||||||||||
Issue descriptionUserAgent: 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 http://codepen.io/thejamespower/pen/rOaxde?editors=110 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 , 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.
, Sep 3 2015I can confirm the CSS Columns Absolute Overflow issue on v45 as well here: http://jsfiddle.net/sjmcpherso/2qaoq1k4/ 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 , Sep 4 2015
==================================== 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: CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/555f740c0f81262c44a5b1e48f1d56af7f6baca9..e0788afb9eb2ed1f530172f70245141567eff43c BLINK CHANGELOG URL: http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&range=195916%3A195912 Suspecting - r195913 Review URL: https://codereview.chromium.org/1152423003 @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. , 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. , Sep 4 2015
, Sep 4 2015
, Sep 4 2015The test case for this bug is http://jsfiddle.net/sjmcpherso/2qaoq1k4/ (comment #5). Attaching a simplified test case with pass condition. , Sep 15 2015
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. , Sep 15 2015
Issue 531809 has been merged into this issue. , Sep 15 2015
Issue 531528 has been merged into this issue. , Sep 16 2015
Issue 532049 has been merged into this issue. , Sep 16 2015Some relevant comments, starting at https://code.google.com/p/chromium/issues/detail?id=471764#c11 , Oct 1 2015Bug 531528 is no longer marked as duplicate. Different issue. , Oct 5 2015
Issue 406349 has been merged into this issue. , Oct 6 2015
Issue 523672 has been merged into this issue. , Oct 7 2015Issue 540541 has been merged into this issue. , Oct 9 2015Issue 541153 has been merged into this issue. , Oct 21 2015Issue 460222 has been merged into this issue. , Oct 28 2015
Issue 548223 has been merged into this issue. , Nov 2 2015Issue 550204 has been merged into this issue. , Nov 12 2015This is quite a serious bug for us, as we use columns heavily on some of our pages, e.g. http://www.theguardian.com/us/sustainable-business , Nov 19 2015Issue 557515 has been merged into this issue. , Dec 1 2015Any progress on this one? It has been identified for almost 3 month now. Or maybe a workaround? , Dec 1 2015I 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. :( , Dec 1 2015It's a shame there's no fix yet, even IE seems to be getting CSS-columns right... , Dec 8 2015Serious 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 , Dec 8 2015I've pinged the review again. , Dec 8 2015For reference, this is the review - https://codereview.chromium.org/1459943002 (Do not add comments there, it will only hinder progress) , Dec 14 2015
Issue 453933 has been merged into this issue. , Dec 21 2015Issue 569050 has been merged into this issue. , Jan 27 2016Issue 530090 has been merged into this issue. , Jan 29 2016possible duplicate https://code.google.com/p/chromium/issues/detail?id=578097 , Jan 29 2016Issue 578097 has been merged into this issue. , Feb 3 2016Confirming that this bug still exists only on chrome. It's been over four months. ... is anybody home? Hello? , Feb 4 2016Believe it or not, but I'm actually working on it. It just requires a bunch of cleanup first. , Mar 17 2016Is 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. , Mar 18 2016
, Mar 21 2016Project MemberThe following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8796ca1186b3ff3e3da105b3ee41f1698be01821 commit 8796ca1186b3ff3e3da105b3ee41f1698be01821 Author: mstensho <mstensho@opera.com> 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 R=leviw@chromium.org Review URL: https://codereview.chromium.org/1819603003 Cr-Commit-Position: refs/heads/master@{#382339} [add] https://crrev.com/8796ca1186b3ff3e3da105b3ee41f1698be01821/third_party/WebKit/LayoutTests/editing/caret/in-multicol-child-expected.html [add] https://crrev.com/8796ca1186b3ff3e3da105b3ee41f1698be01821/third_party/WebKit/LayoutTests/editing/caret/in-multicol-child.html [add] https://crrev.com/8796ca1186b3ff3e3da105b3ee41f1698be01821/third_party/WebKit/LayoutTests/fast/multicol/abspos-in-overflow-hidden-in-2nd-column-expected.html [add] https://crrev.com/8796ca1186b3ff3e3da105b3ee41f1698be01821/third_party/WebKit/LayoutTests/fast/multicol/abspos-in-overflow-hidden-in-2nd-column.html [modify] https://crrev.com/8796ca1186b3ff3e3da105b3ee41f1698be01821/third_party/WebKit/Source/core/editing/CaretBase.cpp [modify] https://crrev.com/8796ca1186b3ff3e3da105b3ee41f1698be01821/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp [modify] https://crrev.com/8796ca1186b3ff3e3da105b3ee41f1698be01821/third_party/WebKit/Source/core/layout/LayoutObject.cpp [modify] https://crrev.com/8796ca1186b3ff3e3da105b3ee41f1698be01821/third_party/WebKit/Source/core/layout/MapCoordinatesTest.cpp [modify] https://crrev.com/8796ca1186b3ff3e3da105b3ee41f1698be01821/third_party/WebKit/Source/core/layout/api/LayoutItem.h , Mar 21 2016
, Apr 12 2016After 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 (http://codepen.io/thejamespower/pen/rOaxde?editors=110) actually does repro and it should have been fixed. We probably have a regression here. Might be also related: http://codepen.io/andry-tino/pen/vGdVWv?editors=1100. However this last one involves only text and requires relative positioning. , Apr 12 2016I 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. , Apr 12 2016I see, so I need to wait for the new version on Chrome to be pushed out and check :) , Apr 12 2016If you want to check right away, you can just download the dev channel of Chrome, since that's already on Chrome 51: https://www.chromium.org/getting-involved/dev-channel , Apr 12 2016I 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! , Apr 12 2016#47 - See https://www.chromium.org/developers/how-tos/get-the-code for getting the code. , Apr 12 2016https://www.chromium.org/developers/how-tos/get-the-code 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. , May 20 2016Issue 612794 has been merged into this issue. , Jun 30 2016This 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: http://codepen.io/jaydenseric/pen/wWdrdQ. 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 :( , 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. https://www.google.com/chrome/browser/canary.html , Jun 30 2016Also, positioned is not transformed... You misunderstood. :( , Jul 1 2016I 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. , Jul 8 2016New bug filed: https://bugs.chromium.org/p/chromium/issues/detail?id=626507 #54 - I can't easily switch to positioning as my transform is a rotate. Looks like overflow hidden and border radius is problematic too: https://bugs.chromium.org/p/chromium/issues/detail?id=531528 Our eyes that follow your cursor didn't render in Chrome due to 3 separate bugs all at once it seems. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by Deleted ...@, Sep 3 2015