LayoutTest http/tests/security/cross-frame-access-put.html is a flaky failure https://build.webkit.org/results/Apple%20Sierra%20Debug%20WK2%20(Tests)/r224335%20(3841)/results.html https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=http%2Ftests%2Fsecurity%2Fcross-frame-access-put.html
It looks like the test pretty much works properly, but dumps the results as a render tree instead of text! Very curious, I wonder if this reproduces locally.
I can reproduce locally with: run-webkit-tests http/tests/security/cross-frame-access-put.html -fg --iter 10 --no-retry-failure
Created attachment 326218 [details] Patch
(In reply to Ryan Haddad from comment #2) > I can reproduce locally with: > run-webkit-tests http/tests/security/cross-frame-access-put.html -fg --iter > 10 --no-retry-failure Thanks for the repro steps Ryan, they worked.
Comment on attachment 326218 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=326218&action=review > LayoutTests/ChangeLog:9 > + Fix flaky test by calling the testRunner functions as early as possible, not in > + the onload event handler. Why does this matter?
Comment on attachment 326218 [details] Patch Clearing flags on attachment: 326218 Committed r224538: <https://trac.webkit.org/changeset/224538>
All reviewed patches have been landed. Closing bug.
Comment on attachment 326218 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=326218&action=review >> LayoutTests/ChangeLog:9 >> + the onload event handler. > > Why does this matter? Because the test can start running in the subframe *before* the onload event handler gets called in the top frame.
> Because the test can start running in the subframe *before* the onload event handler gets called in the top frame. It definitely can, but how does this translate into the symptom? The test should still switch to text mode before any of the content is dumped in the end.
(In reply to Alexey Proskuryakov from comment #9) > > Because the test can start running in the subframe *before* the onload event handler gets called in the top frame. > > It definitely can, but how does this translate into the symptom? The test > should still switch to text mode before any of the content is dumped in the > end. The test starts running in the subframe, then the subframes starts the test in the topFrame via a postMessage(). As far as I can tell, nothing prevented the test in the top frame to finish *before* the onload event handler was called in the main frame. Therefore, the test *could* finish *before* calling testRunner.dumpAsText() is called.
Any test that doesn't call waitUntilDone() finishes after onload is dispatched, so I still don't see how anything could go wrong. I suspect that there is a deeper root cause, something with incorrect sequence of load event and API callbacks.
<rdar://problem/35567537>