LayoutTest fast/dom/Window/window-properties-performance-resource-timing.html is a flaky failure https://build.webkit.org/results/Apple%20Sierra%20Debug%20WK2%20(Tests)/r210559%20(1599)/results.html https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=fast%2Fdom%2FWindow%2Fwindow-properties-performance-resource-timing.html --- /Volumes/Data/slave/sierra-debug-tests-wk2/build/layout-test-results/fast/dom/Window/window-properties-performance-resource-timing-expected.txt +++ /Volumes/Data/slave/sierra-debug-tests-wk2/build/layout-test-results/fast/dom/Window/window-properties-performance-resource-timing-actual.txt @@ -42,6 +42,12 @@ window.performance.timing.unloadEventEnd [number] window.performance.timing.unloadEventStart [number] window.performance.timing [printed above as window.performance.timing] -window.performance.navigation [printed above as window.performance.navigation] +window.performance.navigation [object PerformanceNavigation] +window.performance.navigation.TYPE_BACK_FORWARD [number] +window.performance.navigation.TYPE_NAVIGATE [number] +window.performance.navigation.TYPE_RELOAD [number] +window.performance.navigation.TYPE_RESERVED [number] +window.performance.navigation.redirectCount [number] +window.performance.navigation.type [number] window.performance [string]
Also seeing a flaky failure with the same diff with test: fast/dom/Window/window-properties-performance.html https://build.webkit.org/results/Apple%20Sierra%20Debug%20WK1%20(Tests)/r210566%20(2403)/results.html
Alexey mentioned to me that this issue could be related to the GC, and looking at the flakiness dashboard, that theory does seem to line up. The test was flaky around the time the new GC was enabled, but has definitely become much flakier in the past two weeks.
The symptom means that window.performance.navigation.__visitedByLogValue__ disappears while the test is running, which would mean that JS wrapper for the object gets collected. The flakiness dashboard only has results since December 12th, and the test was failing in the same way back then. So, I don't think that we can find out if the test was failing in the same way before concurrent GC (which was enabled on the 11th). It's possible that concurrent GC is simply more effective at quickly collecting the wrapper, and the bug is in the bindings. I do not know if one needs to do anything custom to protect the GC wrapper these days. Do we still need to add visitAdditionalChildren() functions everywhere?
Marked the two tests as flaky in https://trac.webkit.org/changeset/210901