Bug 285705

Summary: element.children index getter returns a wrong element when traversing backwards
Product: WebKit Reporter: Timo Tijhof <ttijhof>
Component: CSSAssignee: Ryosuke Niwa <rniwa>
Status: RESOLVED FIXED    
Severity: Major CC: ahmad.saleem792, bfulgham, koivisto, rik, rniwa, simon.fraser, webkit-bug-importer, webkit.org, zalan
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
Attachments:
Description Flags
What the test case looks like when the bug happens in Safari
none
Expected behavior as observed in Firefox and Chrome
none
Further reduction showing issue with HTMLCollection
none
Test none

Timo Tijhof
Reported 2025-01-09 13:21:19 PST
Created attachment 473848 [details] What the test case looks like when the bug happens in Safari Steps: * From a click handler, change class name of DOM node X from A to B, and change the class of DOM node Y from B to A. Actual behaviour: According to reading out `node.className`, the change is applied. However in the actual rendering, it seems something somewhere is getting confused and the painted/composited element continues to render as before the change, in perpetuity. Even after many seconds and other paint cycles, the state never corrects itself. It seems to be specific to cases where X and Y are the first and last child of a common ancestor. Online example: * https://treasure21.timotijhof.net/play.html * Press up twice (move class from 1-1 to 0-1 and then wrap to 3-1). * Press down once (effectively copies instead of moves the class from 3-1 back to 0-1). Isolated test: * https://codepen.io/Krinkle/pen/WbeMPvw?editors=0010 * Press "Up" button 2 times. * Press "Down" button 1 time. This logs to the console the value of node.className, which has correctly changed. Yet, the painted element and the inspector's DOM disagree. Other information: * Affects Safari 17.5 on macOS. * Affects Safari 18.2 on macOS. * Affects Mobile Safari on iOS 18.2. * Does not affect Firefox 134. * Does not affect Chrome 131.
Attachments
What the test case looks like when the bug happens in Safari (392.30 KB, image/png)
2025-01-09 13:21 PST, Timo Tijhof
no flags
Expected behavior as observed in Firefox and Chrome (265.51 KB, image/png)
2025-01-09 13:21 PST, Timo Tijhof
no flags
Further reduction showing issue with HTMLCollection (1.50 KB, text/html)
2025-01-11 12:17 PST, Ricci Adams
no flags
Test (921 bytes, text/html)
2025-01-15 01:14 PST, Ryosuke Niwa
no flags
Timo Tijhof
Comment 1 2025-01-09 13:21:47 PST
Created attachment 473849 [details] Expected behavior as observed in Firefox and Chrome
Simon Fraser (smfr)
Comment 2 2025-01-09 13:26:43 PST
Maybe a style sharing bug? It's not repaint; a window resize does not fix it.
Ricci Adams
Comment 3 2025-01-11 12:16:53 PST
It's something to do with HTMLCollection. If an out-of-bounds index is used, subsequent calls will return the first element. Attaching a further reduction which demonstrates this. Tested in Safari 17.6.
Ricci Adams
Comment 4 2025-01-11 12:17:13 PST
Created attachment 473867 [details] Further reduction showing issue with HTMLCollection
Radar WebKit Bug Importer
Comment 5 2025-01-13 14:23:47 PST
Ryosuke Niwa
Comment 6 2025-01-15 01:14:17 PST
Ryosuke Niwa
Comment 7 2025-01-15 11:39:07 PST
EWS
Comment 8 2025-01-15 15:03:52 PST
Committed 288969@main (5b32e928bc97): <https://commits.webkit.org/288969@main> Reviewed commits have been landed. Closing PR #39090 and removing active labels.
Note You need to log in before you can comment on or make changes to this bug.