The following layout test is a flaky timeout on iOS Release: http/tests/navigation/page-cache-domcache-pending-promise.html Steps to Reproduce: run-webkit-tests --ios-simulator --no-retry --no-sample-on-timeout --child-processes 1 -g --iter 100 http/tests/navigation/page-cache-domcache-pending-promise.html Test History: https://results.webkit.org/?suite=layout-tests&test=http%2Ftests%2Fnavigation%2Fpage-cache-domcache-pending-promise.html&platform=ios Diff: --- /Volumes/Data/slave/ios-simulator-13-release-tests-wk2/build/layout-test-results/http/tests/navigation/page-cache-domcache-pending-promise-expected.txt +++ /Volumes/Data/slave/ios-simulator-13-release-tests-wk2/build/layout-test-results/http/tests/navigation/page-cache-domcache-pending-promise-actual.txt @@ -1,15 +1,5 @@ -Tests that a page with pending DOMCache activity goes into the page cache. +#PID UNRESPONSIVE - WebKitTestRunnerApp (pid 92071) +FAIL: Timed out waiting for notifyDone to be called -On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". - - -pageshow - not from cache -pagehide - entering cache -pageshow - from cache -PASS Page was restored from Page Cache -PASS Cache.add() succeeded -PASS !!restoredFromPageCache is true -PASS successfullyParsed is true - -TEST COMPLETE - +#EOF +#EOF
<rdar://problem/56590038>
Looking into this now.
Unfortunately, run-webkit-tests --ios-simulator --no-retry --no-sample-on-timeout --child-processes 1 -g --iter 100 http/tests/navigation/page-cache-domcache-pending-promise.htm does NOT reproduce it for me :/
This test's run time is all over the place - 1 second, 6 seconds, 26 seconds, timeout...
(In reply to Chris Dumez from comment #3) > Unfortunately, run-webkit-tests --ios-simulator --no-retry > --no-sample-on-timeout --child-processes 1 -g --iter 100 > http/tests/navigation/page-cache-domcache-pending-promise.htm > > does NOT reproduce it for me :/ No luck reproducing this on my second machine either.
Still not able to reproduce this.
I see this logging in stderr on the bots: CONSOLE MESSAGE: line 23: Fetch API cannot load http://127.0.0.1:8000/navigation/resources/blank.txt due to access control checks. But I think that's expected.
Created attachment 383652 [details] Patch
Created attachment 383748 [details] Patch
Comment on attachment 383748 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=383748&action=review > LayoutTests/ChangeLog:12 > + Speculative fixes: This is failing EWS
Comment on attachment 383748 [details] Patch Will investigate.
(In reply to Chris Dumez from comment #11) > Comment on attachment 383748 [details] > Patch > > Will investigate. Very odd, this test is passing for me locally on Mac-wk2.
Created attachment 383804 [details] Patch
I cannot reproduce it locally but it looks like caches.open() flakily times out on the iOS wk2 and macOS wk2 bots for some reason.
Created attachment 383878 [details] Patch
Ping review? EWS was able to reproduce the flakiness previously so it looks like this did the trick.
This is slowing down EWS sometimes. e.g.: In https://ews-build.webkit.org/#/builders/24/builds/5353 this test failed while running layout-tests, and EWS had to re-run layout-tests in which it passed. If the test wasn't flaky, the re-run wouldn't have been required.
Comment on attachment 383878 [details] Patch Clearing flags on attachment: 383878 Committed r252769: <https://trac.webkit.org/changeset/252769>
All reviewed patches have been landed. Closing bug.