Steps to reproduce the problem

1. Cannot provide steps to reproduce - see problem description.

Problem Description

We have an automated test suite that utilizes Selenium/Maven/JUnit/Java. We currently have over 600 automated test cases for one of our applications, and these test cases have been running successfully for years on Chrome/Chromedriver. Since Chrome 134, however, about 20% of our test cases have started failing with StaleElementReferenceExceptions, and it happens on every run.

Our application is built using Java (JSP) (ie: is old school and not very dynamic). As such, our page object methods look something like this:

public void clickSaveButton() { driver.findElement(...).click(); }

public void clickNextButton() { driver.findElement(...).click(); }

That is, we always re-locate elements before interacting with them (we don't hang onto them waiting for them to become stale). Practically speaking, stale element exceptions should be rare under such circumstances (and were, prior to v134).

I've tried using old versions of our code (to ensure that code changes on our end weren't causing the issue) and rolling the browser/driver back to v132 and v130, but to no avail (even though we previously used both those versions of Chrome successfully when they were current).

I note a similar issue (albeit not relating to stale elements) has been reported by the Capybara team here: https://github.com/teamcapybara/capybara/issues/2800. In that issue, one commenter points out that rolling back to Chrome v128 fixed the issue for him (https://github.com/teamcapybara/capybara/issues/2800#issuecomment-2735137297). I can confirm that rolling back to Chrome v128 also fixes the problem for me.

I'm attaching Chromedriver log extracts from both v134 and v128. Both logs cover the same test case around the point where v134 throws a StaleElementException. The scenario involves clicking on a "Save" button (to save a document to the server), then clicking a "Next" button to move to the next page. In the v128 log, it appears as though the navigations are completed before the response is received from ClickElement for the Save button. But in the v134 log, the Save button click returns before the resultant navigations take place. FindElement is then called for the "Next" button. The Save button navigations appear to occur during the FindElement operation, probably causing the DOM to be refreshed after the Next button is located and hence, the element becoming stale before it is clicked (I should point out that I'm no expert at interpreting the chrome log, and that I've had to redact some of the details to hide our URLs etc. Hopefully, this doesn't negate their usefulness in diagnosing this issue).

Not surprisingly, the Edge browser/driver exhibits the same behaviour (stale elements since v134).

I also noticed that the release notes for Chrome v134 indicate that there were changes relating to preload policies, but I'm not sure if that might be related to this issue or not. If so, is there a flag we can pass to the chromedriver options to revert to the old browser behaviour?

Technologies used: Selenium: v3.14 and v4.17 (2 separate branches with different Selenium versions. Both worked successfully up to Chrome 134). JDK: jdk-13.0.1 Maven: 3.9.6 Chrome/Chromedriver: 134.0.6998.89 (for failed tests); 128.0.6613.137 (for successful tests)

Summary

StaleElementReferenceExceptions occurring with Chrome v134.

Custom Questions

Please select a label to classify your issue:

Type-Bug-Regression - Used to work, now broken

Additional Data

Category: Other
Chrome Channel: Stable
Regression: Yes