1700879 - v87.0 update broke all Material Design tables in our application

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[merissa.silk]

Attachment: fundingport-v87.zip

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

Steps to reproduce:

Opened firefox
Updated to version 87.0
navigated to state.fundingport.energy/re/
logged in
viewed various screens inside the application

Actual results:

We're using Material Design tables, I believe, and all of them are now broken inside our applications. I checked several screens, and the spacing (height) of the rows is HUGE and is significantly different from how the tables viewed in FF v86. What's odd is that they are not broken in a consistent way

Expected results:

The tables should appear same as they do in v86

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Hi, thanks for reporting this. Instead of screenshots, is there any chance you could attach a sample of the HTML that misbehaves? That'd make figuring this out much easier. Thanks!

Comment 3

[merissa.silk]

Attachment: fundingport-pages.zip

Hi, I'm less familiar with grabbing code from Firefox, is the attached what you're after?

Comment 4

[merissa.silk]

Attachment: Fundingport - Operations (26_03_2021 10_20_10).html

Here's one more example -- is this the right one? We're seeing the issue with tables generally across our applications... so I can provide samples from other screens if needed.

Comment 5

[Daniel Holbert [:dholbert]]

Thanks! That example in comment 4 is perfect; I can reproduce the change.

Google Chrome (version 91 dev) agrees with Firefox's updated rendering -- it renders your testcase the same way that Firefox 87+ does (though Chrome versions 89 release and 90 beta do match Firefox's older rendering). So I think what we're seeing here was actually a bug fix that Firefox and Chrome have both made around the same time. If you like the old behavior, you can style your table with align-self:start to opt it out of the flexbox stretching behavior. (EDIT: actually you'd probably want flex-start, not start, since Chrome doesn't support the start keyword yet; and the two keywords usually mean the same thing anyway.)

Comment 6

[Daniel Holbert [:dholbert]]

Nightly 2021-02-18 is the first nightly that shows the new behavior, so I'm pretty confident that bug 1674302 would've been the thing that changed behavior here, and it was indeed an intentional change in behavior (to align with the spec). As noted above, Chrome has made the same fix in version 91.

And as noted above, CSS table { align-self:flex-start } is probably the workaround you would want to use, if you prefer the old behavior.

(Or, kind-of equivalently, you could add align-items:flex-start to the parent element of any affected table.)

Comment 7

[Daniel Holbert [:dholbert]]

I filed https://github.com/mui-org/material-ui/issues/25555 on the library here (Material-UI, https://material-ui.com/ ), so they can adapt to the new behavior and hopefully roll out a fixed version that addresses this on their end, without individual webapps needing workarounds.

Comment 8

[Daniel Holbert [:dholbert]]

CC @biesi & @dgrogan as an FYI - you may see similar reports for the analogous change to table-flex-item-stretching that you made in Chrome 91. (not sure what the exact Chromium issue-page or assignee was there, though maybe you do.)

Comment 9

[dgrogan (chrome)]

!

Thanks for the heads up.

Comment 10

[Daniel Holbert [:dholbert]]

Actually, it looks like the display:flex styling here (on the table's container) isn't coming from Material UI -- it's coming from a class .jss1241, as noted in my above-linked github mui-org bug report.

So, the issue here isn't really a "Material UI"-specific change, but rather it's an issue with the fact that this particular site is putting tables (any tables at all) in this .jss1241 element, which happens to be a flex container; and tables' behaviors as flex items are changing to address this longstanding inconsistency, as noted above.