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

Issue 849945 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Setting an explicit height on content in a grid changes the "height: 100%" calc for sibling elements

Reported by matthewd...@gmail.com, Jun 6 2018

Issue description

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

Steps to reproduce the problem:
1. Go to https://codepen.io/matthewdean/pen/LrZxjX
2. Note that the "toothpick" element in the grid row is set to height: 100%
3. When its sibling element has inherent height (height from content), and as such pushes the grid row to that height, then the toothpick is full height, however;
4. When its sibling element has an explicit height (inline style), even though it sets the grid row height, the height: 100% calculation fails.

What is the expected behavior?
height: 100% should be 100% of the grid row height. Changing the sibling element to an explicit height (vs. auto) should not change the height: 100% calculation of a sibling

What went wrong?
The toothpick's 100% calculation changes based on whether the grid row height is being set intrinsically or explicitly.

Did this work before? No 

Does this work in other browsers? No
 This is working correctly in Firefox.
This is failing in the same way in Safari.

Chrome version: 66.0.3359.181  Channel: n/a
OS Version: OS X 10.12.6
Flash Version: Shockwave Flash 29.0 r0
 
Labels: Needs-Triage-M66

Comment 2 by tkent@chromium.org, Jun 6 2018

Components: Blink>Layout
Cc: sindhu.chelamcherla@chromium.org
Labels: Triaged-ET M-69 Target-69 FoundIn-69 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on reported version 66.0.3359.181, on latest stable and latest canary 69.0.3450.0 using Windows 10, Mac 10.13.3 and Ubuntu 17.10.

This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged.

Thanks!

Comment 4 by e...@chromium.org, Jun 7 2018

Components: -Blink>Layout Blink>Layout>Grid
Status: Available (was: Untriaged)

Comment 5 by r...@igalia.com, Jun 7 2018

Cc: svil...@igalia.com r...@igalia.com jfernan...@igalia.com
Thanks for the bug report.
Please could you explain better how to reproduce the issue, provide a screenshot or something.
In the codepen I see no differences in Firefox vs Chromium rendering,
attaching a screenshot of Chromium rendering.

BTW, note that the simpler the test case, the easier to identify the root cause and fix it (see https://developer.mozilla.org/en-US/docs/Mozilla/QA/Reducing_testcases).
Screenshot from 2018-06-07 23-34-49.png
33.2 KB View Download
Well this is what I WAS seeing (I screenshotted from Safari just now), but I'm frankly baffled, because I can't reproduce it either. It isn't happening as of Chrome 67.0.3396.79, and even before it updated from 66 to 67 this morning, I couldn't reproduce. And I couldn't reproduce on Safari on my MacBook at home this morning where I have High Sierra installed. So... fixed in both places?
Screen Shot 2018-06-08 at 10.37.01 AM.png
34.1 KB View Download

Comment 7 by r...@igalia.com, Jun 8 2018

Owner: r...@igalia.com
Status: WontFix (was: Available)
Ok, I was not understanding the problem as comment #3 said it was reproducible on stable and canary too.

There have been fixes in both Chromium and WebKit related to percentages, so yeah it might be fixed but one of those.
Good to know it's working as expected now.
Hang on.... it's not working as expected in my app, but working with the reduced test case that I created based on the problem in my app. What the.... will investigate more. I was able to reproduce with that Codepen; it's just that codepen is (currently? temporarily?) working.

Comment 9 by r...@igalia.com, Jun 8 2018

Mmmm, until we have a test case that is broken on trunk/Canary we cannot help much more.
If you have a different test that doesn't work on Canary, please share it.

You can try to bisect it and find the commit that fixed the issue if you like, but I'm not sure if that's really important at this stage.

There are other issues with percentages and grids, we've some bug reports about them, and they'll hopefully get fixed at some point.

Sign in to add a comment