Uneven height of td element when using fractional heights on children
Reported by
michalmm...@gmail.com,
Nov 29 2017
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce the problem: 1. Create an html table in which table cells have various content (images / text). 2. Set font size with vw units. 3. Set size of images with vw units. 4. Notice in devtools that height of table cells differs. Full working examples: 1. https://stackoverflow.com/questions/47561966/chrome-td-height-when-using-vw 2. https://jsfiddle.net/Lh6wqts6/ What is the expected behavior? Table cells within a row should have exact same height. What went wrong? Height of table cells differs slightly if in a single row there are cells with content of various height set with vw unit. These differences are sub-pixel values (usually between 0.1 - 0.5px). At some screen resolutions, when this difference is particularly high (ca. 0.5px), this leads to clearly visible misaligned borders (see attachments). Did this work before? Yes 61.0.3163.100 Does this work in other browsers? Yes Chrome version: 62.0.3202.94 Channel: stable OS Version: Ubuntu 14.04 Flash Version: Tested on Browserstack Win10 / Chrome 61 and works as expected. Tested on Ubuntu 14.04 / Firefox 57 and works as expected.
,
Nov 30 2017
,
Dec 1 2017
Able to reproduce the issue on Windows 10, mac 10.12.6 and Ubuntu 14.04 using chrome reported version #62.0.3202.94 and latest canary #64.0.3281.0. Bisect Information: ===================== Good build: 62.0.3169.0 Revision(490187) Bad Build : 62.0.3170.0 Revision(490562) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/97eedd95bbffdf6b2a24494a599a5089bcad1f94..abc4634436dd4fc1b909ec04e589288464d432aa From the above change log suspecting below change Change-Id: I15850c55d54fbb0c885d4040be3c90ea2a51d7ca Reviewed-on: https://chromium-review.googlesource.com/543141 eae@ - Could you please check whether this is caused with respect to author: karlo@ change, if not please help us in assigning it to the right owner. Note: Assigning it to the reviewer of the issue as the author doesn't seems to be available since 30 days. Thanks...!!
,
Dec 14 2017
This is a recent regression, can we get a fix during M65 time frame?
,
Dec 14 2017
Would you mind taking a look at this when you get a chance kojii?
,
Dec 19 2017
I can see dev tools reporting different height, but can't reproduce visible misaligned borders in Canary. Some of the suspect was changed in issue 771318 and I wonder if this is no longer reproducible. Can you please: 1. Check with Canary and see if this is still reproducible? 2. If so, this isn't about the "vw" units, but about setting fractional length to the height of <img>. Can you tell us the computed height of <img>s when it reproduces? You can probably reproduce by replacing "vw" values with computed "px" values. It helps to reproduce without making my window size exactly the same as yours.
,
Dec 19 2017
,
Dec 19 2017
I can't reproduce the testcase either.
,
Jan 4 2018
michalmmalik@ Ping! Could you please respond for the comment #6 ? Thanks!
,
Jan 4 2018
Hi all, "I can see dev tools reporting different height, but can't reproduce visible misaligned borders in Canary." Isn't it a sufficient indication of an incorrect behavior? Why would <td /> elements within a single row be of various height in the first place? Seeing misaligned lines is only a side-effect. "1. Check with Canary and see if this is still reproducible?" Just checked on Version 65.0.3298.3 (Official Build) dev (64-bit) / Ubuntu 16.04. The issue is still reproducible. "If so, this isn't about the "vw" units, but about setting fractional length to the height of <img>. Can you tell us the computed height of <img>s when it reproduces? You can probably reproduce by replacing "vw" values with computed "px" values. It helps to reproduce without making my window size exactly the same as yours." See attached files. Cheers, Michal
,
Jan 4 2018
Removing RBS as there's no user visible regression but only values in dev tools. Maybe JS getBoundingClientRect() is affected too, haven't checked yet, but that doesn't seem to qualify RBS/p1. Please feel free to change it back if this understanding doesn't look good.
,
Jan 4 2018
I do not agree that there is no user-visible regression. As I mentioned in my previous post, when using Canary, I still can *fully* reproduce the bug I described in the initial post. This includes visible misalignment of table lines (on some screen widths). Take a closer look at the recently uploaded images (down right cell of the table).
,
Jan 5 2018
#13: > Take a closer look at the recently uploaded images (down right cell of the table). Confirmed, thank you for pointing this out.
,
Nov 30
> Needs-Feedback What kind of feedback do you need? Can I help you solve this problem, somehow?
,
Nov 30
Thank you for checking, no it was left over. Removed.
,
Dec 12
,
Dec 12
Attaching simplified test case (no need for vw or images). The test uses getBoundingClientRect().height on two sibling table cells differ by a fraction of a pixel. I checked, and I can see that the LayoutBox::frame_rect_ heights do actually differ. I cannot reproduce the border glitch (with the jsfiddle demo), though. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by manoranj...@chromium.org
, Nov 29 2017