Closed Bug 1700879 Opened 8 months ago Closed 8 months ago

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


(Core :: Layout, defect)

Firefox 87





(Reporter:, Unassigned)





(3 files)

Attached file

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
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

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.

Component: Untriaged → Layout
Product: Firefox → Core

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!

Flags: needinfo?(
Attached file

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

Flags: needinfo?(

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.

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.)

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.)

Closed: 8 months ago
Regressions: 1674302
Resolution: --- → INVALID
Regressed by: 1674302
No longer regressions: 1674302

I filed on the library here (Material-UI, ), 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.

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.)


Thanks for the heads up.

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.

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