Consider: <table id="t"></table> <script> let table = document.getElementById("t"); for (let i = 0; i < 1000; i++) { table.appendChild(document.createElement("tr")); } document.body.offsetWidth; // flush t.firstChild.style.display = "none"; document.body.offsetWidth; // flush </script> When we remove the frame of the first <tr> element and then flush, we will end up posting an nsChangeHint_ReconstructFrame on the <table>, because we decide we need to re-evaluate whether the <tr>s are grouped appropriately into anonymous table row group frames. This is due to the rules in CSS 2 https://www.w3.org/TR/CSS22/tables.html#anonymous-boxes that say contiguous table row boxes that otherwise wouldn't have a table row group box parent must be wrapped by a single anonymous table row group box. We blow away the frames to avoid handling a bunch of different cases of merging and splitting the anonymous table row group box. This is done here: https://searchfox.org/mozilla-central/rev/a80651653faa78fa4dfbd238d099c2aad1cec304/layout/base/nsCSSFrameConstructor.cpp#11669-11834 But for a common case where we remove or insert a table row frame into/from an anonymous table row group frame, where the previous and next siblings are table row frames, we should be able to avoid this, because we know we don't need to change which anonymous table row group frames we have.

(In reply to Cameron McCormack (:heycam) (busy until July 12) from comment #0) > But for a common case where we remove or insert a table row frame into/from > an anonymous table row group frame, where the previous and next siblings are > table row frames, we should be able to avoid this, because we know we don't or even the case where one of the siblings matches and the other sibling is missing. Also, Dan had a testcase that triggered this (which we had him modify to avoid triggering this), that would be useful to attach here.

This test case iterates rows of a table without a tbody, setting display:none on each row. It spends a lot of time creating tables.

I'd also note that of all the cases involving anonymous table boxes, this one seems the most worth optimizing, because people creating tables from script are pretty likely not to have a <tbody> element, since they forget or don't know that it's normally there. This makes me suspect that it's likely to be the most common case of anonymous table box reconstruction, although I haven't attempted to gather any data to check this.

(Note that the testcase was originally created for bug 1330375.)