Drupal\Tests\views\FunctionalJavascript\Plugin\views\Handler\FilterTest is failing a lot at the moment

+++ b/core/modules/views/tests/src/FunctionalJavascript/Plugin/views/Handler/FilterTest.php
@@ -121,9 +121,11 @@ protected function filterVisibleElements($elements) {
-    return $page->waitFor($timeout / 1000, function () use ($count, $page, $locator) {
+    return $page->waitFor($timeout / 1000, function () use ($count, $page, $locator, &$final_count) {

not clear where $final_count is used, moreover it's not defined in the function body

Annoying nit alert:

--- a/core/tests/Drupal/Tests/DocumentElement.php
+++ b/core/tests/Drupal/Tests/DocumentElement.php
@@ -85,4 +88,31 @@ public function getText() {

+      // If the callback has only fired once then in might be really slow. In

+ // If the callback has only fired once then it

In #34, the failure is with JSWebWithWebDriverAssertTest::testJsWebAssert. That is not listed on #2829040: [meta] Known intermittent, random, and environment-specific test failures so I was wondering if a new random error was being introduced. I searched for that test and find that it did fail in the most recent batch of random failures that occurred 21 and 22 July of this year. It is also failing random in #3315074-21: What's going on with JS testing discovery issue. So, not a new random error.

This is a definitive improvement!

JSWebAssertTest and JSWebWithWebDriverAssertTest still seem to have issues, but this is overall such an improvement on the current situation that I'm going to RTBC.

The troubles there seem to be based on a test that asserts if a element that should dissappear after X is still there before X has passed.
I think that's kinda a niche case where waitFor could still fail, but that's for the next issue IMHO.

Not sure it makes sense to commit patch which does not pass tests, the issue here is because of runner's performance and DA could move to faster instance

The test suite shouldn't depend on how fast the test runners are though, I think we need to get this in, which should result in green along with the other change in #3315074: What's going on with JS testing discovery issue.

Committed/pushed to 10.1.x, cherry-picked back through to 9.4.x, thanks!

@andypost: I see what you're saying, but (at least for me) there's a difference between not green and less red.

The current JS test fail-storm is rather big. Most probably, as you said, caused by upped performance on our test-CI (damn you, progress!!!).

Looking for One-Patch-To-Rule/Greenify-Them-All, might be one step beyond, by chopping it into smaller fixes (that will still not be fully green) we might be able to get to the Goal of Green quicker.

INSTA-EDIT: Outtyped _and_ outcommitted, I'm getting too slow for this game...;)

@alexpott: Ah, misinterpreted the performance the wrong way around. Thanks for clearing that up.