Bug 280852 – Table DOM manipulations that require reflow do not always trigger reflow

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

Currently when using Safari (all recent versions including Safari 18), performing DOM manipulations on Table elements that should trigger reflows do not always trigger reflows. A simple reproducible case is shown in the following codepen:

https://codepen.io/turjmner8/pen/ExqKaMo

In this example, a <table> and wrapping <div> structure is setup, and after a timeout of 5 seconds, an extra column is added to the <table> along with 'style' attribute of the <table> being removed. At this point, the <table> should become wider than the 300px it was previously constrained to be, but it remains at 300px and forces cell contents to wrap instead. When running the same codepen in other major browsers (Edge, Chrome, Firefox, etc...), the resulting width of the Table is larger and allows for no cell contents to require text wrapping.

Additionally, sometimes opening the web inspector is enough to trigger the <table> width to 'jump' to the correct, larger width. Otherwise, using the web inspector to do something trivial like toggle the :active state on the <table> element will cause the width to 'jump' to the larger, correct width.

The expectation here is that the final larger width should be applied to the <table> without requiring some additional update or reflow trigger.

[alan baradlay]

Created attachment 472806 [details]
test reduction

fixed table layout's shrink-to-fit width invalidation issue.

[alan baradlay]

Created attachment 472809 [details]
[fast-cq]Patch

[EWS]

Committed 284698@main (f6a9f208c8d7): <https://commits.webkit.org/284698@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 472809 [details].

[Radar WebKit Bug Importer]

<rdar://problem/137300794>