Closed Bug 1879731 Opened 5 months ago Closed 4 months ago

Wrong table css rendering when tbody is updated after table is loaded

Categories

(Core :: Layout: Tables, defect)

Firefox 122
defect

Tracking

()

RESOLVED FIXED
125 Branch
Tracking Status
firefox125 --- fixed

People

(Reporter: biral.mattia, Assigned: dshin)

References

Details

Attachments

(6 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:122.0) Gecko/20100101 Firefox/122.0

Steps to reproduce:

I wrote a JavaScript program that creates an empty table (thead, tbody and tfoot are created, tbody is empty).
In thead there are two tr. The first one contains th "groups", headers that span across columns, the second one contains specific headers.
The "group" headers have borders at their right and left.
Then the program fetches through an API some data that is put into the tbody.

Actual results:

When the content is loaded the "group" headers' borders span across the table vertically, this is not correct, in fact in other browsers (e.g. Chrome) it does not render like this.

Expected results:

Said borders should not span vertically across the table (that anyway has strange and strict css rules, but that's another thing).
In fact, if I force the rendering of the table (e.g. settings display='none' and then display='') it renders correctly.
So I've implemented the code below to make the page render it correctly:
$('#table').hide();
setTimeout(function() {
$('#table').show();
}, 0);
Below the first screenshot shows the weirdly rendered table, the second shows the correctly rendered one obtained running the above script.

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.

Component: Untriaged → Layout: Tables
Product: Firefox → Core

Thanks for reporting! Could you attach an html testcase via the "Attach New File" to demonstrate the issue you described in comment 0?

Flags: needinfo?(biral.mattia)

Of course. I'm busy today, but tomorrow I'll upload a simplified case in a single html file.

Here is a super simple, commented, single html file that showcases the bug.
Press 'Load Data' to see how the table is incorrectly rendered.
Then press 'Fix' to issue a redraw and see the correctly rendered table.

Flags: needinfo?(biral.mattia)

Please do something because this bug is really annoying.

Thank you for attaching the testcase!

David, you've been looking into border-collapse table code. Could you triage and take a look? I feels like to we fail to trigger table invalidation when new table rows get inserted?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dshin)
  1. We mark the damage area as the new inserted row
  2. Damage area is expanded by one cell in all directions
  3. We no longer mark the start of the new 0px width border segment, because the previous border information is initially populated with "no border" values.
  4. We never end the 2px border segment, so it continues all the way to the bottom
Flags: needinfo?(dshin)
Severity: -- → S3
Assignee: nobody → dshin
See Also: → 1880560
Pushed by dshin@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a463e87b55f0
Correctly fill out previous last border information at row and column edges in border-collapsed tables. r=layout-reviewers,emilio
https://hg.mozilla.org/integration/autoland/rev/ddda3c5cc909
Address clang-tidy concerns in BCMapCellIterator. r=layout-reviewers,emilio
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/44813 for changes under testing/web-platform/tests
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 125 Branch
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: