RESOLVED FIXED280759
REGRESSION (Safari 18): DOM manipulations that require reflow do not always trigger reflow
https://bugs.webkit.org/show_bug.cgi?id=280759
Summary REGRESSION (Safari 18): DOM manipulations that require reflow do not always t...
jmturner8
Reported 2024-10-02 08:47:48 PDT
Starting with Safari 18, it looks like there is a regression in the layout of certain elements due to specific DOM manipulations where necessary reflows or layout recalculations can be missed. I am working on a simple codepen to show this, but in the meantime the issue can be seen using the public facing demos for the Oracle JET Table here: https://www.oracle.com/webfolder/technetwork/jet/content/table-gridStyling/demo.html?theme=redwood&cssVars=default&debug=min&dir=ltr&fontSize=fontnone&color=default&notagcss=true&scale=lg&density=standard The resulting DOM in this link will show a <div> and an <oj-table> custom element wrapping a <table> element that is allowed to grow to fit its contents. In all major browsers besides Safari 18 (Chrome, Firefox, Edge, Safari 17 and older), four columns worth of data are fully visible, with a vertical scrollbar allowing a user to see more content below. In Safari 18 though, the outer 2 wrapping elements have a stale width of 240px that looks like it is due to a min-width setting on the outer <oj-table> custom element. Nothing else about the DOM structure should be resulting in that width of 240px though, and the inner <table> element should be forcing the wrapping elements to grow to match its width of 600+ px. Sometimes, just opening the web inspector in Safari will actually trigger the wrapping element widths to jump to the correct, larger size. Otherwise, using the web inspector to find the <oj-table> element, and triggering any kind of simple update to it will cause it to jump to the correct width (I usually just toggle the :active state on/off with the web inspector after selecting it). So far, if I create the same setup in a simple codepen with all of the same DOM and styling applied up front, the width is always correct and the issue does not reproduce. In the real product code though, the DOM is created dynamically and the timing of that DOM manipulation seems to be the root cause of this reflow / recalc being missed.
Attachments
Test reduction (323 bytes, text/html)
2024-10-03 17:12 PDT, alan
no flags
Screenshot with fix applied (locally) (781.18 KB, image/png)
2024-10-03 17:39 PDT, alan
no flags
Patch (3.38 KB, patch)
2024-10-03 20:40 PDT, alan
no flags
[fast-cq]Patch (4.04 KB, patch)
2024-10-04 05:28 PDT, alan
no flags
jmturner8
Comment 1 2024-10-02 16:07:41 PDT
With the link above, sometimes you need to refresh the page to see the issue, though it is fairly consistent in being the wrong width.
jmturner8
Comment 2 2024-10-02 19:48:44 PDT
I added a simple codepen that reproduces the issue - when running in Safari 18 (and also older versions of Safari), the overall size of the outer div is only 240px instead of much wider. When opening web inspector and making any trivial change (such as toggling the :active state on the outer div), the width is adjusted correctly. https://codepen.io/turjmner8/pen/dyxMyLR
Alexey Proskuryakov
Comment 3 2024-10-03 15:01:42 PDT
Thank you for the report! I can reproduce this issue with STP 200.
Radar WebKit Bug Importer
Comment 4 2024-10-03 15:01:54 PDT
alan
Comment 5 2024-10-03 17:12:13 PDT
Created attachment 472797 [details] Test reduction
alan
Comment 6 2024-10-03 17:39:00 PDT
Created attachment 472799 [details] Screenshot with fix applied (locally) We seem to be missing a preferred with invalidation on the containing block when child goes from out-of-flow to inflow.
alan
Comment 7 2024-10-03 20:40:34 PDT
jmturner8
Comment 8 2024-10-03 22:04:33 PDT
Thanks for the quick replies - am wondering if the fix for this issue also addresses this similar bug I also filed: https://bugs.webkit.org/show_bug.cgi?id=280852 I couldn't quite tell if this was the same underlying issue as this other case where reflow was being missed seemed worth filing a separate bug for. Thanks!
alan
Comment 9 2024-10-04 05:28:00 PDT
Created attachment 472805 [details] [fast-cq]Patch
alan
Comment 10 2024-10-04 05:31:01 PDT
(In reply to jmturner8 from comment #8) > Thanks for the quick replies - am wondering if the fix for this issue also > addresses this similar bug I also filed: > > https://bugs.webkit.org/show_bug.cgi?id=280852 Yeah, I saw that too. Thanks for filing it! > > I couldn't quite tell if this was the same underlying issue as this other > case where reflow was being missed seemed worth filing a separate bug for. It's totally worth filing a separate bug! It's easier to mark it duplicate than dealing with multiple issues under one bug.
EWS
Comment 11 2024-10-04 08:00:54 PDT
Committed 284679@main (80c060940757): <https://commits.webkit.org/284679@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 472805 [details].
Sammy Gill
Comment 12 2024-12-11 14:37:10 PST
*** Bug 247578 has been marked as a duplicate of this bug. ***
alan
Comment 13 2025-01-17 06:32:23 PST
*** Bug 286062 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.