Shadow table rendering miscalculation after content update
Reported by
giovann...@gmail.com,
Sep 30 2016
|
|||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 Example URL: https://jsfiddle.net/thg2k/anom72c9/ Steps to reproduce the problem: 1. Observe shadow initial rendering 2. Click "remove last row" link 3. Click "fix up" link What is the expected behavior? After removing the line, the shadow should still look the same What went wrong? I suspect there is a miscalculation on the position of the shadow after child content update, it does not account for the table border, but it is influenced by the border collapse and the cells height. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? Yes Chrome version: 53.0.2785.143 (Official Build) m (64-bit) Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Tested on Chrome 51 on linux, same problem happens.
,
Sep 30 2016
box-shadow doesn't use CSS filters. I'm suspecting a paint invalidation problem? Or maybe a layout problem, since it looks like the area between the element and the text below is insufficient for the shadow.
,
Oct 3 2016
I think it's a layout issue. Agree with senorblanco's reasoning.
,
Oct 5 2016
Retested the issue on Windows 10, Ubuntu 14.04 and Mac OS 10.11.6 using reported version #53.0.2785.143 and latest canary #55.0.2880.4 as per comment #0. The steps followed to reproduce the issue are as follows: ---------- 1. Navigated to url https://jsfiddle.net/thg2k/anom72c9/ 2. Clicked "remove last row" link 3. Clicked "fix up" link 4. Observed that after removing the line, the shadow showed initial rendering as expected. Hence, the issue is not reproducible. Attaching screencast for the same. Reporter@ - Could you please verify the screencast and let us know if anything missed from our side. Thanks,
,
Oct 5 2016
Dude the bug IS clearly visible in your screen cast, *BEFORE* clicking "fix up"
,
Oct 5 2016
Thanks for your clarification....!! I will be providing the bisect info.
,
Oct 5 2016
Able to reproduce the issue on MAC 10.11.6, Windows 10 and Ubuntu 14.04 using chrome reported version #53.0.2785.143 and latest canary #55.0.2880.4 This is a non regression as it is observed from M35, M45 and M50 old builds. Hence, marking it as untriaged to get more inputs from dev team. Thanks,
,
Oct 5 2016
,
Oct 5 2016
,
Oct 27 2016
If we change the style as this, we can see it more clear:
<style>
table.buggy {
background-color: #ffffff;
border-collapse: collapse;
border: 10px solid green;
}
tr td {
height: 70px;
vertical-align: text-top;
}
</style>
And when I changed the fix_refresh as below, it also works well.
fix_refresh = function() {
document.getElementById('refreshMe').style.height = '81px';
document.getElementsByClassName('price')[0].style.backgroundColor ='red';
document.getElementsByClassName('price')[0].style.width='0px';
}
So I think the root cause is refreshMe is re-layouted when fix_refresh is called, while price not.
BTW, when remove border-collapse: collapse, it works well like FF.
,
Oct 27 2016
Hi, I am interested with this issue, and I am looking for a proper place to force the td's get layouted when its sibling's style is changed.
,
Oct 28 2016
,
Oct 28 2016
,
Oct 30 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 30 2017
Still broken
,
Oct 31 2017
Bug confirmed on Chrome 62.0.3202.75 Please keep this open, it is definitely not something you can ignore, as I actually ran into this while doing actual development.
,
Oct 31
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 5
|
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by schenney@chromium.org
, Sep 30 2016Components: -Blink Blink>CSS>Filters Blink>Paint
Status: Available (was: Unconfirmed)