[Webkit-unassigned] [Bug 280759] New: regression (Safari 18) DOM manipulations that require reflow do not always trigger reflow

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=280759

            Bug ID: 280759
           Summary: regression (Safari 18) DOM manipulations that require
                    reflow do not always trigger reflow
           Product: WebKit
           Version: Safari 18
          Hardware: All
                OS: Unspecified
            Status: NEW
          Severity: Critical
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jmturner8 at gmail.com
                CC: bfulgham at webkit.org, simon.fraser at apple.com,
                    zalan at apple.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20241002/7bf064d5/attachment-0001.htm>