Created attachment 381683 [details] Repro attempt #1

It seems 500 runs wasn’t enough to reproduce the failure :(

The test is a lot more flaky than that, so I don't think that it's about the number of iterations. Another possibility is that there is something in a preceding test that breaks this one. Also the results history suggests that this may be more reproducible with a physical device.

(In reply to Alexey Proskuryakov from comment #5) > The test is a lot more flaky than that, so I don't think that it's about the > number of iterations. Another possibility is that there is something in a > preceding test that breaks this one. > > Also the results history suggests that this may be more reproducible with a > physical device. I am aware that this is failing pretty frequently on internal bots. However, I wasn’t able to glean any useful information from their output :/ The test group that’s run prior to this test is fast/forms/fieldset, and then fast/forms/ios/accessory-bar-navigation.html is the first test of the fast/forms/ios group. The first thing I tried was to keep on running fast/forms/fieldset and then fast/forms/ios/accessory-bar-navigation.html for many iterations, but this yielded no reproduction. I did discover, however, that the failure output in this test is identical to what would occur if a software keyboard were to be presented instead of the usual hardware keyboard. This is the strongest lead so far. I suspect that something (in another system framework, or maybe even another test running in a different simulator) is either somehow causing this simulator to think the hardware keyboard is not attached, or is somehow rendering the SPI we call to ensure that the hardware keyboard is attached (GSEventSetHardwareKeyboardAttached) ineffective. I tried to run this test (accessory-bar-navigation.html) between other tests in fast/forms/ios to try and capture this state — hence the random “xyz” prefixes in front of each cloned layout test. But it seems this didn’t work either.

Alexey and I discovered a way to consistently reproduce this failure (🥳). The key is to run the test on a newly created iOS simulator; the first test run in this manner will use a software keyboard instead of a hardware keyboard. The following invocation works for me: ``` run-webkit-tests --ios-simulator --debug --no-retry-failures --no-show-results --no-sample-on-timeout fast/forms/ios/accessory-bar-navigation.html --child-processes 1 ``` Calling off the queued EWS jobs.

Created attachment 381939 [details] Patch

The commit-queue encountered the following flaky tests while processing attachment 381939 [details]: The commit-queue is continuing to process your patch.

The commit-queue encountered the following flaky tests while processing attachment 381939 [details]: imported/w3c/web-platform-tests/IndexedDB/interleaved-cursors-small.html bug 203433 The commit-queue is continuing to process your patch.

Created attachment 381965 [details] Fix a ChangeLog typo

Committed: https://trac.webkit.org/changeset/251601/webkit.