1919918 - width of tbody may exceed its parent table on Windows when display is at 150%

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect)

Description

[programming]

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

Steps to reproduce:

The Windows computer display must be set to 150%. This step triggers the bug!

Create a table with content that takes up a good chunk of the monitor.
The table should have characteristics like so font-family: Verdana, sans-serif; color: #333; text-align: center; border-top-width: 1px; border-bottom-width: 1px; border-left-width: 1px; border-right-width: 1px; box-sizing: border-box; background: #fff; padding: 1rem; border-radius: 8px; box-shadow: 0 0 10px rgba(0,0,0,0.1); margin: 0 auto; display: inline-block; width: 80%; border-collapse: separate; border-spacing: 0px;

The tbody has no special style.
The table header/rows have style font-family: Verdana, sans-serif; color: #333; border-collapse: separate; border-spacing: 0px; box-sizing: border-box; text-align: center; border: 1px solid #101010; padding: 4px 6px; white-space: normal; overflow-wrap: break-word;

This will cause the tbody to display wider than the table itself. There is a website where this 100% reproducible, but it requires particular input images, though it may still produce a page with this bug with any images. The URL is https://rosslab.einsteinmedneuroscience.org/odes

Actual results:

tbody exceeds width of parent table

Expected results:

table should be wider than tbody

Comment 1

[BugBot [:suhaib / :marco]]

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

Comment 2

[programming]

I have temporarily changed referenced URL to workaround the bug. This class must be assigned to see the bug

.content {
background: #fff;
padding: 1rem;
border-radius: 8px;
box-shadow: 0 0 10px rgba(0,0,0,0.1);
margin: 0 auto;
display: inline-block; // Make the table inline-block so it can be centered
width: 95%; // Ensure the content takes full width
//overflow-x: auto; Allow horizontal scrolling if needed
}

Comment 3

[Daniel Holbert [:dholbert]]

Thanks for the bug report. I tried adding those styles to the .content rule in Firefox and Chromium and I do see the page layout change, but it changes in the same way in both browsers, so I'm not seeing the bug yet (assuming this is a Firefox-specific issue). We'll need a bit more information in order to investigate here.

In Comment 0 you mentioned "it requires particular input images" -- I assume you have to use the "choose files" button on the page that you linked to, in order to get those images into the page to trigger the bug -- is that correct?

If you've got sample images that you can share which trigger the bug and clear steps-to-reproduce using those images, perhaps you could post those images as attachments here? (I imagine the image-size is all that matters, so you might get images from e.g. https://placehold.co/ and confirm that they work, and then provide those images along with your steps here, so that you're not e.g. having to share actual patient data or whatever.)

BUT -- even better -- if it's possible to just create a static copy of the page somewhere that demonstrates the issue (with the images already in the page so no interaction is required), that'd be even better. (Given that you have access to the web server, I imagine you might be able to do that?)

Also:

The Windows computer display must be set to 150%. This step triggers the bug!

It's possible it can also be reproduced in a machine with 100% pixel-scaling as long as full-page-zoom is set to 150% (e.g. "Ctrl+" or Ctrl+Mousewheel until 150% is shown in the URL bar). Full-page-zoom uses mostly the same underlying implementation details as the system pixel-scaling zoom. Just mentioning this in case it makes the bug easier to reproduce/investigate at some point.

Comment 4

[programming]

I put the problem page on a dedicated page, https://einsteinmedneuroscience.org/table/index.html

Comment 5

[programming]

One more thing, Chrome is also affected the same way: https://issues.chromium.org/issues/368388538

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to programming from comment #5)

One more thing, Chrome is also affected the same way: https://issues.chromium.org/issues/368388538

If distinct browser engines are affected by the same unexpected-behavior, that's often a clue that it's not actually a browser bug but is something more subtle. :)

(In reply to programming from comment #4)

I put the problem page on a dedicated page, https://einsteinmedneuroscience.org/table/index.html

So looking at that page, I do indeed see that the <tbody> element overflows the <table> element (as visualized by their borders), if my window size is small enough relative to the content-width.

That's because the page has CSS that styles the <table> to be not-actually-a-table, I think. The page has:

.content {
  [...]
  display: inline-block;

...which applies to the <table class="content" element.

So what ends up happening is that the tbody sees that its parent-box is not-a-table -- its parent box is an inline-block -- and it generates an anonymous table box with default styles, and that table box shrinkwraps its width, and those two together overflow beyond the bounds of its inline-block-<table> parent. Or something along those lines.

Really, you probably want to style your table with display:inline-table rather than inline-block and then things will behave as you expect.

--> Closing as INVALID because this seems to have been a misunderstanding without a tbody box actually overflowing a display:table box.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

(In reply to programming from comment #5)

One more thing, Chrome is also affected the same way: https://issues.chromium.org/issues/368388538

If distinct browser engines are affected by the same unexpected-behavior, that's often a clue that it's not actually a browser bug but is something more subtle. :)

Safari/WebKit matches Chrome and Firefox's rendering here, too, so it seems there's in fact pretty good interoperability around this rather than a browser-specific bug.

Comment 8

[programming]

Oh, wow. Thanks.