The following layout test is flaky on Mac Release WK2 editing/execCommand/insert-nested-lists.html Probable cause: This test became flakey with https://trac.webkit.org/changeset/244182/webkit I reproduced this issue with command: run-webkit-tests editing/execCommand/insert-nested-lists.html --iterations 500 -f The test fails randomly on 244182 and passes fully on 244181. Flakiness Dashboard: https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=editing%2FexecCommand%2Finsert-nested-lists.html Diff: --- /Volumes/Data/slave/mojave-release-tests-wk2/build/layout-test-results/editing/execCommand/insert-nested-lists-expected.txt +++ /Volumes/Data/slave/mojave-release-tests-wk2/build/layout-test-results/editing/execCommand/insert-nested-lists-actual.txt @@ -43,52 +43,39 @@ | <br> | <ol> | <li> -| "bar" -| <ul> -| <li> -| <#selection-caret> +| <#selection-caret> After selecting a range and inserting another unordered list: | <ul> | <li> | "foo" | <br> -| <ol> +| <ul> | <li> -| "bar" -| <ul> +| <#selection-caret> +| <ol> | <li> -| <#selection-caret> -| <ul> -| <li> After outdenting: | <ul> | <li> | "foo" | <br> -| <ol> -| <li> -| "bar" -| <li> -| <#selection-caret> -| <br> -| <ul> -| <ul> -| <li> +| <li> +| <#selection-caret> +| <br> +| <ul> +| <ol> +| <li> After outdenting again: | <ul> | <li> | "foo" | <br> -| <ol> -| <li> -| "bar" -| <li> -| "baz<#selection-caret>" -| <br> -| <ol> -| <ul> -| <ul> -| <li> +| "baz<#selection-caret>" +| <br> +| <ul> +| <ul> +| <ol> +| <li>
<rdar://problem/49954111>
This is a bit surprising. This test doesn't use rAF, and generally looks like it should be deterministic. Said, Wenson, any ideas on how the regression could happen here?
(In reply to Alexey Proskuryakov from comment #2) > This is a bit surprising. This test doesn't use rAF, and generally looks > like it should be deterministic. > > Said, Wenson, any ideas on how the regression could happen here? It actually does use requestAnimationFrame: await new Promise(resolve => requestAnimationFrame(resolve));
Found another editing test regressed by r244182. Linking to 197065
There is no reason to believe that waiting for rAF would cause UI process' runloop to run. So we need to be making an explicit round trip to UI process instead.
Created attachment 367811 [details] Fixes the test
Committed r244461: <https://trac.webkit.org/changeset/244461>
Looks like the flakiness is gone!