Duplicate deprecation header messages break Chromedriver

I can confirm the error locally. Without the fix, the test with "Element 'Log in' not found", and it passes with the fix. How bizarre!

+++ b/core/modules/user/tests/src/FunctionalJavascript/UserLoginTest.php
@@ -0,0 +1,37 @@
+  /**
+   * {@inheritdoc}
+   */
+  protected $profile = 'standard';

It's important that it is the standard profile right? I'm pretty sure that this is because of how we communicate deprecation messages using browser headers.

Wow, that is very impressive! No idea why #3 makes the test pass but #8 does as well. Maybe @hchonov can confirm.

Here's a simpler test that fails with Chromedriver for me. Creating just 100 deprecation messages passed, so I went with 1000 didn't dig any further on what number specifically is required to trigger a fail, but even with 1000 it was fast enough locally that I don't think we have to worry about it too much. Don't have PhantomJS locally, so curious what the Testbot will say. If the "tests-only" patch passes, we will have to explicitly override the Mink driver class for now until #2942900: Convert JavascriptTestBase Tests to use DrupalSelenium2Driver lands.

Alright, DrupalSelenium2Driver it is, then.

II'm not sure about the test - because it might pass if chromedriver suddenly supported more header messages - or if you swap out chromedriver for geckodriver or selenium. I think maybe we should think about the approach. I.e. should we change the communication away from headers and use a file. Or should we change the test to test on the number of deprecation messages and assert that they cannot be duplicated.

Hmm... I'm fine with updating the test to assert on the number of assertion messages.

If we want to pursue using a file instead, I have no problem with that in general, but then it would be nice to get this in without a test first, because it is causing problems for us.

Updating the title and issue summary, though, now that we have proof what the problem is.

OK, here's an updated test that just asserts on the number of matching headers.

This one should be green. Also fixes a stale comment.

The counting of headers has been implemented by tstoeckler as announced. Looks good to me.
We've been running our custom tests with #24 for some time already.

Unfortunately this needs a reroll on supported branches (9.0.x, 8.9.x, and 8.8.x) - it needs to be fixed there.

Committed and pushed de3bb2cc24 to 9.0.x and faeb170e9f to 8.9.x and 44873f2d1e to 8.8.x. Thanks!

Backported to 8.8.x as a test only bug fix.