Wrong table css rendering when tbody is updated after table is loaded
Categories
(Core :: Layout: Tables, defect)
Tracking
()
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.
Comment 1•5 months ago
|
||
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•5 months ago
|
||
Thanks for reporting! Could you attach an html testcase via the "Attach New File" to demonstrate the issue you described in comment 0?
Reporter | ||
Comment 3•5 months ago
|
||
Of course. I'm busy today, but tomorrow I'll upload a simplified case in a single html file.
Reporter | ||
Comment 4•5 months ago
|
||
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.
Reporter | ||
Comment 5•5 months ago
|
||
Please do something because this bug is really annoying.
Comment 6•5 months ago
|
||
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?
Assignee | ||
Comment 7•5 months ago
•
|
||
- We mark the damage area as the new inserted row
- Damage area is expanded by one cell in all directions
- 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.
- We never end the 2px border segment, so it continues all the way to the bottom
Assignee | ||
Updated•5 months ago
|
Assignee | ||
Comment 8•5 months ago
|
||
Assignee | ||
Updated•5 months ago
|
Assignee | ||
Comment 9•4 months ago
|
||
Assignee | ||
Comment 10•4 months ago
|
||
Depends on D202232
Comment 11•4 months ago
|
||
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
Comment 13•4 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/a463e87b55f0
https://hg.mozilla.org/mozilla-central/rev/ddda3c5cc909
Upstream PR merged by moz-wptsync-bot
Description
•