Some test fixes #1834
Some test fixes #1834
Conversation
Wait for the registry search to show the expected value *before* doing the pixel test. Also, the dialog's filter is already set to "Local", that was done just a few lines above. Drop the redundant click.
That dialog switches between the "All" and "Local" filter of images. The busybox image is shown in both views; however, it gets re-rendered on switch, so clicking on it is a race condition -- without waiting the click often goes to the *old* "All" result. We can't directly wait on that transition. So switch to a different registry filter first, wait for the "No images found", and then switch to "Local", so that our `wait_visible()` can take over.
These were introduced in commit a47c186 without justification, and it's not clear what they were meant to do. Depending on the timing they change/mess up the value in the file choosers, leading to random test failures.
Enabling the disabled element only works when clicking on the [ - ] or [ + ] buttons, not the number itself. With Firefox the test will soon click into the center of the element, which is the number. Make the selector more specific to ensure it goes to the [ - ] button. Also circumvent the "element must be not enabled" restriction by directly using `Browser.mouse()`. This has always been a race condition, as we expect the number input to be disabled by default.
|
Ah, this run found a similar bug as the testCreateContainerInPodUser() failure, and locally I then found yet another one. Also, the "create button eternally disabled in pod dialog" fails a lot here. @jelly is investigating that right now, for this PR I'll just lean on the retry button for these for one or two rounds, and otherwise ignore them. |
|
Hm, we've had this failure twice now:
But well, all the other TF tests passed, so good enough. |
Split out from #1832.
I'll trigger an extra /firefox run.