Closed Bug 1528030 Opened 5 years ago Closed 5 years ago

Overflow text breaks out of CSS Grid cells

Categories

(Core :: Layout: Grid, defect, P3)

65 Branch
defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox-esr60 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- affected

People

(Reporter: garciacarrillo.daniel, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: parity-chrome, parity-edge, regression, Whiteboard: [triagemonth-2019-02])

Attachments

(4 files)

Attached image Firefox 65.0.1.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.81 Safari/537.36

Steps to reproduce:

I created a grid layout containing a grid cell that has text-overflow: ellipsis.

Test environments
Firefox 65.0.1 macOS Mojave
Firefox 67.0a1 (2019-02-14) nightly macOS Mojave
Firefox 65 Windows 10 (via BrowserStack)
Chrome 72 macOS Mojave
Edge (18) Windows 10 (via BrowserStack)
Safari 12.0.3

I've made a codepen to repro or you can view the code below:
https://codepen.io/danielgarciacarrillo/pen/qgMZNg?editors=1100

<div id="grid">
<div class="cell">
A
</div>
<div class="cell">
<div class="truncated-text">CSS is wonderful and always works as expected</div>
</div>
<div class="cell">C</div>
<div class="cell">D</div>
</div>

#grid {
display: grid;
grid-template-columns: repeat(4, 1fr);
gap: 8px;
width: 340px;
border: 1px solid black;
}

.cell {
grid-column: span 2 / auto;
border: 1px solid red;
}

.truncated-text {
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
}

Actual results:

The grid cell, which contains overflowing text, expanded to fit the text content.

Expected results:

The text should have been truncated with an ellipsis and the cell should match the size of other cells in the grid.

Safari, Edge and Chrome exhibit the desired behavior

Hi Daniel Garcia-Carrillo,

Thanks for taking your time for reporting this bug!

As per your STR, I was able to reproduce this bug with Firefox 65.0.1 on Windows 10, 64 Bit.

Hence, I am confirming the bug!

Component: Untriaged → General
Flags: needinfo?(asa)
Whiteboard: [triagemonth-2019-02]

Sorry Asa, Done it mistakenly, while was trying to n'info in another bug.

Flags: needinfo?(asa)
Component: General → Layout: Grid
Product: Firefox → Core

Regression window(layout.css.grid.enabled=true):
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bb03ea15520d120bb6bff4d1d7227c3744feec5f&tochange=282e4426f1e19175f6374be13fe9065da433ab44

Suspect: Bug 1176775

mats,
Your bunch of patch seems to cause the regression. Can you please look into this?

Blocks: css-grid, 1176775
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mats)

I'm pretty sure this is actually the correct/expected outcome from that patch, and I think Chrome's behavior is incorrect here.

I'll file a Chrome bug. In the meantime, min-width:0 on the grid item is an effective workaround for cases when our (spec-compliant AFAICT) behavior is causing trouble.

(I think this is kind of a grid version of https://bugs.chromium.org/p/chromium/issues/detail?id=487302 and friends, basically.)

Attached file reduced testcase 1

Hmm, after playing around with a testcase, I'm less sure about what's going on & how the grid properties + min-width:auto interact here. So, I'll hold off on filing a Chrome bug because I'm not sure what I'd say.

Here's a testcase, with 4 different grids. Firefox/Chrome disagree on the first one (its grid item is wide in firefox but skinny in Chrome), but they agree on all the others.

The Firefox/Chrome behavior-difference seems in part due to the handling of min-width:auto, because I can make Firefox match Chrome by simply adding min-width:0 to the item. However, there's more going on, because Firefox is OK with making the second grid's grid-item skinny.... And (on the flip side) Chrome agrees that the third and fourth grid item are not-skinny. And all of those grid items have the same contents and have the default min-width:auto value as well.

Mats, do you know what's going on here (and would you mind filing a Chrome bug if appropriate?)

Priority: -- → P3
Attached file Testcase #2

Well, the codepen in comment 0 doesn't render as in the attached
screenshot, neither in 65.0.1 nor in Nightly, so I don't know
what to make of that..

Looking at "reduced testcase 1" instead: yes, we handle this
correctly for the most part... i.e. the item should definitely
overflow. (adding min-width:0 on the grid item will probably
give the results the author intended)

However, there's also a somewhat recent (10 months, gulp)
Grid spec change that we haven't implemented yet:
https://drafts.csswg.org/css-grid/#algo-spanning-flex-items
added in:
https://github.com/w3c/csswg-drafts/commit/25e3f631310207ed83746530b4066b6278c3234f
for:
https://github.com/w3c/csswg-drafts/issues/2177

So while the rendering looks correct in Firefox, it's not.
The column size should not be 50px 50px, but 101px 101px as
demonstrated in this testcase.

Step 4 in the algo should (I think) give the same result as
"grid-template-columns: auto auto" for this particular case
(not in general though).

Flags: needinfo?(mats)

I filed bug 1530097 about implementing the new Step 4 in the track sizing algo.

This bug as filed is invalid, because the item should overflow
and the rendering in Chrome is wrong.
I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=935102

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID

(In reply to Mats Palmgren (:mats) from comment #7)

Well, the codepen in comment 0 doesn't render as in the attached
screenshot, neither in 65.0.1 nor in Nightly, so I don't know
what to make of that..

I spoke to the reporter on Friday -- it looks like he made some edits to the live codepen in the time since filing the bug, while we tryied to sort out the best way to work around this compat issue -- and it seems that these updates inadvertently made it into the testcase that'd he'd provided for this bug report.

(This is a good reason to avoid codepen for bug reports - testcases may change by accident and then cause confusion down the line.)

Anyway: here's his original testcase, if you're interested. The key thing that's present in the codepen now (& which avoids the bug is) max-width:100%, which (like min-width:0) works around the bug.

Note that the reporter's testcase used 1fr rather than 50px (as shown in my just-posted attachment), whereas I switched to pixel values in my "reduced testcase 1", to simplify things a bit.

But I assume the same analysis still applies (the track should still grow to accommodate the spanning item's min-content size).

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: