[BUG] HTML Table Rendering Bug with border-collapse: collapse

Description of the issue:
HTML Table Rendering Bug in Latest Brave Browser
border-collapse: collapse is making the table behave incorrectly which triggers paint issues in latest Brave browser.

Steps to Reproduce (add as many as necessary):
1.To reproduce the problem, I have created a sample CodePen which sets two tables:
1- border-collapse: collapse;
2- border-collapse: separate;

I would like to ask someone to view the CodePen and try it out by setting/removing values from the input boxes.

There is a border painting bug. The issue can be solved by resizing the browser or by setting any CSS rule that triggers a DOM repaint process.

The left table uses border-collapse: collapse; and repaints weirdly when input values are set and cleared.

The right table uses border-collapse: separate; and it is painting and rendering as expected.

Actual Result (gifs and screenshots are welcome!):
The left table here: https://codepen.io/mhdSid/pen/XWRMmZJ

Expected R esult:
The right table here: https://codepen.io/mhdSid/pen/XWRMmZJ

Reproduces how often:
All the time

Brave Version(See the About Brave page in the main menu):
[
Version 1.26.74 Chromium: 91.0.4472.124 (Official Build) (x86_64)
]

Reproducible on current live release (yes/no):
Yes

Additional information:

@Sippi333,
Thanks for reaching out to us.
Perhaps I’m misunderstanding the issue or how to produce it, but on my end the table borders appear to be just fine with either css property value:
image

1 Like

Hello @Mattches

Thank you for your response. Have you tried setting and clearing values in the input fields?

This is the result that I’m getting

The borders of the left table shiver and blink.

@Sippi333,
Yeah I did and nothing looks off to me. Here’s a short recording of the behavior – am I missing something here?

border

@Mattches Have you tried settings values in multiple fields and checking that all borders are okay? Please try filling data in all the three fields of the table and keep clearing/setting in all of the fields in order to reproduce the bug.

What type of display are you using? Does the issue resolve itself if you use a thicker border?

@sampson I’m using a Mac-os 2.4 GHz 8-Core Intel Core i9, 32 GB 2667 MHz DDR4, with Intel UHD Graphics 630 1536 MB and 16-inch screen Retina display. I’m sorry but thicker borders do not resolve the issue.

I was able to reproduce the issue. Let me take a closer look and share what I find.

1 Like

I suspect there is indeed an issue with the renderer here; I’m able to reproduce the issue. That said, I don’t think it’s due (exclusively) to the collapsed borders. We start to get a clearer understanding of the issue when we crank up the thickness of the borders.

Here’s the code I’m using below for tests:

CSS:

body > table:first-child {
    border-collapse: collapse;
}

td {
    border-left: 10px solid red;
    border-right: 10px solid green;
    border-top: 10px solid orange;
    border-bottom: 10px solid pink;
}

table {
    display: inline-table;
    vertical-align: top;
}

HTML:

<table class="first-table">
    <caption>Collapsed</caption>
    <tr><td><input /></td></tr>
</table>

<table class="second-table">
    <caption>Not Collapsed</caption>
    <tr><td><input /></td></tr>
</table>

JavaScript:

document.addEventListener("input", ({ target }) => {
    const result = target.value && target.value.length <= 2;
    target.style.marginBottom = result ? "3em" : "0em";
});

By default, have a look at how the borders are arranged for both tables.

Brave:
image

Edge:
image

Chrome:
image

Chrome is clearly doing something different with the table. But since Edge and Brave make no major changes to this part of the Chromium source, I suspect this different is due to experimental field trials being enabled in Chrome for particular (or all) users. You can see which variations are enabled for your instance of Chrome by visiting chrome://version.

When you something that changes the dimensions of the table, the renderer tries to intelligently repaint that section of the viewport. Unfortunately, it fails to do so as expected. We wind up with clear artifacts from the original layout:

image

Note the original left-border (red) remaining above. We can force a repaint by opening the developer tools (right-click, select Inspect Element), and this appears to fix things:

image

Of course, once we remove the input, causing the layout to be repainted, a new set of artifacts appear:

image

These types of rendering bugs are pesky, and appear from time to time. Google may already have a solution in place in Chromium, and are testing it out on users before turning it on by default for all users (including those who inherit the fix via Edge and Brave).

In the meantime, you can help the renderer by performing actions which force a repaint. One example is a non-discernable animation on the element itself. For example:

body > table:first-child {
    border-collapse: collapse;
    animation: rock 2s infinite;
}

@keyframes rock {
    to { transform: translateX(0px) }
}

This animation causes the browser to constantly track the element, and make sure that it’s painted properly. Not a great solution, but better than pesky artifacts.

force-browser-repaint

I hope this helps for now; I do hope to see this issue resolved natively in a future build.

1 Like