Navigation issues after updating Chrome to 134.0.6998.35

[Zoltán Lehóczky]

After updating Chrome from 133.0.6943.141 to 134.0.6998.35 we noticed very strange navigation behavior with our .NET Selenium tests, primarily around navigation. The symptoms are "random" and include ChromeDriver.Navigate().GoToUrlAsync() not actually navigating, or the driver not waiting for the page load after POST-ing a form (but handing back controller sooner, while it still loads).

I'm still investigating this, so can't tell anything more coherent.

Does this ring a bell for anybody?

[Cody Lerum]

We are seeing the same or similar issue after updating to Chrome 134 with our chrome headless github actions failing.

The issue appears to be that when clicking a button or link that cause a navigation, the driver no longer waits for the navigation to be complete and for the page to be ready.

[Kevin Locke]

On Friday, March 14, 2025 at 1:00:11 AM UTC pyroc...@gmail.com wrote:

After updating Chrome from 133.0.6943.141 to 134.0.6998.35 we noticed very strange navigation behavior with our .NET Selenium tests, primarily around navigation. The symptoms are "random" and include ChromeDriver.Navigate().GoToUrlAsync() not actually navigating, or the driver not waiting for the page load after POST-ing a form (but handing back controller sooner, while it still loads).

I've noticed a similar issue using .NET:  With Edge 134 (134.0.3124.51, .66, and .68) .Click() method calls on <button>s which trigger navigation via POST form submission sometimes (~20%?) return before page navigation completes.  Downgrading to Edge 133.0.3065.92 has been an effective workaround for us.

https://github.com/SeleniumHQ/selenium/issues/15404 reports a similar issue (and links to this thread, which is how I found it).

I'd like to help investigate and resolve the issue.  I hope to produce a minimal reproduction as I have time, but that's unlikely in the next few days.

Thanks for reporting this issue and for anyone investigating,
Kevin

[Aashima Gandhi]

We are experiencing similar issue "Caught org.openqa.selenium.ElementNotInteractableException: element not interactable " while running our selenium tests in headless mode with chrome 134+ . Navigation actions are not getting performed like hover over and selecting values from typeahead field .We have tried using implicit , explicit waits , scroll into view , visibility of element and action class but the issue is not properly resolved .

If anyone have tried fixing this with workaround, please let us know.

Also , Can we expect some fix from Chrome ?

[Zoltán Lehóczky]

My guess is around 20% unreliability too. We worked around this by retrying ChromeDriver.Navigate().GoToUrlAsync() until the previously retrieved "html" IWebElement starts to throw StaleElementReferenceException (i.e. we can be sure that we left the page). You can check out our implementation by starting from here: https://github.com/Lombiq/UI-Testing-Toolbox/blob/fcf83f6b5fe7d591e4066c2e86dadf28351b22e6/Lombiq.Tests.UI/Extensions/NavigationUITestContextExtensions.cs#L62

For form POSTs not waiting for the page load, we implemented application-specific explicit waits for success messages.

The whole thing feels as if PageLoadStrategy (https://www.selenium.dev/documentation/webdriver/drivers/options/#pageloadstrategy) switched to Eager from Normal (but it didn't, and all this with only a Chrome, not Selenium.WebDriver update).

[Shakul Pareek]

We are facing similar issue with hover over on menu, submenu items and TypeAhead

Driver throws ElementNotInteractableException 

Any workarounds for this issue?

On Tuesday, March 18, 2025 at 9:57:14 AM UTC+5:30 ke...@kevinlocke.name wrote:

[Zoltán Lehóczky]

These issues also remain when using Selenium Manager, indicating that some kind of browser-driver mismatch is not the cause of the problem.

An additional symptom is that button clicks became unreliable. Not just that sending a single click might not result in an actual click (what was always the case and what we have retries in place for) but also that even with retries, clicks won't do anything. Even if we close the session and open a new one (i.e. also a new browser window), retried tests consistently exhibit this issue. However, this issue surfacing during a given CI run (Ubuntu 24.04 GitHub Actions runners) is random; the same button will work just fine on the first try once, but break and remain broken during retries in another run ("run" corresponding to single-use VM).

[Zoltán Lehóczky]

One thing I discovered that Selenium Manager may use the installed browser if the major-minor versions are matching (e.g. it may use the installed 134.0.6998.166 version if 134.0.6998.165 is requested). By setting the SE_FORCE_BROWSER_DOWNLOAD environment variable to "true" you can enforce that the exact version is used.

[Zoltán Lehóczky]

Two further workarounds/observations:

This might be caused by Chrome displaying a warning about unsafe passwords, which dims the whole viewport and makes UI interactions unreliable. Setting the following configs in ChromeOptions (using C# as an example below) fixed that for me:

options.AddArgument("--password-store=basic");
options.AddUserProfilePreference("credentials_enable_service", "false");
options.AddUserProfilePreference("profile.password_manager_enabled", "false");
options.AddUserProfilePreference("reduce-security-for-testing", "null");
options.AddUserProfilePreference("profile.password_manager_leak_detection", "false");
options.AddArgument("--suppress-message-center-popups");

You can make Selenium use a given exact Chrome version with Selenium Manager (https://www.selenium.dev/documentation/selenium_manager/). In C#, this can be done with:

options.BrowserVersion = "134.0.6998.165";

But additionally, see https://github.com/SeleniumHQ/selenium/issues/15517, you need to set the SE_FORCE_BROWSER_DOWNLOAD environment variable in your code (or in the system):

Environment.SetEnvironmentVariable("SE_FORCE_BROWSER_DOWNLOAD", "true");

While getting rid of the unsafe password warning is what probably fixed these issues for me for good (not sure, because at that point I added a bunch of workarounds), having a fixed browser version is what makes tests properly reproducible across environments.

[Craig]

I'm seeing a similar issue in my environment. About 20% of tests failing, mostly with StaleElementReferenceExceptions, that only started with Chrome v134. Flaky behaviour is mostly happening around POSTs and page loads, but is very random (always causing about 20% failure rate though). Only the browser was updated between tests working and becoming flaky (ie: no changes to driver, application under test, environments etc). I created a report here:

https://issues.chromium.org/issues/405607581

But there hasn't been much movement on that one yet. As mentioned in that issue, downgrading to Chrome v128 has been a successful (hopefully temporary) workaround for me.

[Zoltán Lehóczky]

Thank you for sharing!

Also, maybe using the Chrome switches under https://github.com/GoogleChrome/chrome-launcher/blob/main/docs/chrome-flags-for-tools.md, especially the ones about rendering background/occluded windows may help. We're using the switches that you can see from here: https://github.com/Lombiq/UI-Testing-Toolbox/blob/23f4312d65169a8c84cc16765765d541c0058fc7/Lombiq.Tests.UI/Services/WebDriverFactory.cs#L153 And they seem to be useful; our tests since implementing all of these workarounds/config changes see very little flakyness.

[Craig]

I've previously tried setting the background/occluded window flags as suggested here: https://github.com/teamcapybara/capybara/issues/2800#issuecomment-2750363862, but this made no difference for me. Today I've picked up a bunch of additional flags (including the occluded ones again) from https://github.com/Lombiq/UI-Testing-Toolbox/blob/23f4312d65169a8c84cc16765765d541c0058fc7/Lombiq.Tests.UI/Services/WebDriverFactory.cs#L153 as per your suggestion, but that hasn't made any difference either unfortunately.

Just to be clear, I'm seeing these stale element exceptions in both headless and normal mode, when running a single test case, or when running multiple tests in parallel or sequential mode. I can therefore see that there are no unsafe password warnings or any other type of popups/dimming etc occurring at the time of the stale element exceptions. Accordingly, I have not tried the unsafe password flags you mentioned.

Our application that is coded using JSP was previously our most stable application in terms of automation, but has been by far the most effected by this issue. It performs frequent POSTs back to the server and this is where I'm seeing most of the flakiness. I haven't found any flags that improve this behaviour. We have other applications that communicate with the server less frequently via API/webservice calls and these applications are less effected, though not completely immune (flakiness occurring around page loads, for example, despite waiting for the document ready state to be complete and elements to be present/clickable).

So it still appears to me to be a change in behaviour in Chrome v134 that is returning control to the driver before navigations are complete. Thus far, rolling back to Chrome v128 has been the only "solution" that works for me. And I find it interesting that rolling back to Chrome/chromedriver v132 and v130 still exhibits the stale element exceptions of v134, even though those versions previously worked. I run on Windows platforms, and I'm wondering if v134 has made changes to the Chrome settings in the Windows registry or something??? That would imply that the changes to Chrome were implemented around v130, but were not enabled prior to v134. But that's just wild speculation at this point.

[Zoltán Lehóczky]

Not a solution but perhaps a workaround you can employ is what we do (has been doing most of it for quite a while before this issue, but stale elements are now indeed a lot more frequent), see below. I'm linking to our codebase for inspiration.

• There can be new "Node with given id does not belong to the document" UnknownErrorException exceptions which are actually StaleElementReferenceExceptions in disguise, so we handle both the same: https://github.com/Lombiq/UI-Testing-Toolbox/blob/6be1a83466f85e8ebfae517eadfd352a3f0111d7/Lombiq.Tests.UI/Extensions/WebDriverExceptionExtensions.cs
• We have methods like RetryIfStaleOrFailAsync() (https://github.com/Lombiq/UI-Testing-Toolbox/blob/6be1a83466f85e8ebfae517eadfd352a3f0111d7/Lombiq.Tests.UI/Helpers/ReliabilityHelper.cs#L201C24-L201C47) that retry any given operation if they get a StaleElementReferenceException-like exception, like clicking repeatedly (https://github.com/Lombiq/UI-Testing-Toolbox/blob/6be1a83466f85e8ebfae517eadfd352a3f0111d7/Lombiq.Tests.UI/Extensions/NavigationWebElementExtensions.cs#L26). Crude, but works for certain cases.
• Similarly, we have retry methods for retrying an operation until the URL changes (as retrieved from the driver) or the page changes (as indicated by the <body> element becoming stale). So, for some forms, we have "click submit until the URL changes".
• When it's about POST-ing, we now mostly explicitly wait for an element to appear. E.g. instead of the test being "click submit button, click <link>", it's now "click submit button, wait for success message to appear, click <link>". It's perhaps better like this anyway.

Naturally, none of these are silver bullets, and you have to employ them case-by-case.

We've seen these issues first under Ubuntu, and then also under Windows, so it's not a Windows-only issue.

[Craig]

That's the "solution" I've been trying to avoid haha. We have a very large automation suite with tens of thousands of lines of code. Updating it to handle all these new stale element exceptions will be a logistical nightmare. 

I guess if push comes to shove I'll explore extending the ChromeDriver/EdgeDriver/RemoteWebElement classes and handle stale elements internally inside the overridden click/sendKeys etc methods. Our driver factory would then just return instances of the new driver classes and that should take care of most of the simple exceptions with minimal changes. Failures occurring around page loads could be handled by overriding the driver's get() method and waiting for URLs to change etc, but I'm not sure that will work in all circumstances. 

I'm still hoping for the Chromium team to say "hey, that's a bug. We'll just fix that for ya". Not holding my breath though...