Update to selenium/standalone-chrome:128

Tried with Chrome 133 and 134, both seem to have failing tests. Also tried to only upgrade in the latest deps job but I guess I messed up the formatting.

Not sure what's changed, but it seems after any kind of pressButton we need to wait for the next page to load. I don't know the best way to do that, but for proof of concept I've introduced a waitForAddressEquals helper. Hope there is a more generic way.

Could we add a ::waitForElement() for those cases or something similar?

re #8: I'm hoping for something more generic, it's quite burdensome figuring out what to wait for after ::pressButton. I've introduced a waitForDocumentReady function which seems to work for most cases. Still not sure what changed in selenium or chrome that means this is necessary though. Still working through the fails but pushing my progress so far.

mstrelan → changed the visibility of the branch 3471113-chrome-update-deps to hidden.

mstrelan → changed the visibility of the branch 3471113-chrome-133 to hidden.

I found 📌 Provide the ability for JS functional tests to track whether the page has been reloaded Closed: outdated and #2936122: Find out why JavscriptTestBase occasionally needs a waitForElement on a normal page load → which are related.

Given the amount of the changes here maybe it's better to just go to 133 first and see if any big brains have better solutions for 134. Opened 📌 Update to selenium/standalone-chrome:133 Active and postponing this.

I got lots of test failures with Chrome 134.

Ref:
https://issues.chromium.org/issues/405607581
https://github.com/teamcapybara/capybara/issues/2800

This issue was recently heavily affecting Drupal LMS → tests where my test plan was one long JS test to improve performance and avoid setting up multiple times and.. there are lots of buttons pressed so it's a very good example.

Here's what we came up with (thanks to @catch for finding all the issues with partial solutions that work combined with a bit of my own logic): https://git.drupalcode.org/project/lms/-/merge_requests/82/diffs#e8d889b...
That combines waiting for a change in page HTML after pressing the button and checking the document.readyState.
Hope that helps, we could implement something similar in core.