Cody Lerum <cody....@gmail.com>: Mar 17 01:20PM -0700
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.
On Thursday, March 13, 2025 at 7:00:11 PM UTC-6 Zoltán Lehóczky wrote:
|
Kevin Locke <ke...@kevinlocke.name>: Mar 16 02:07PM -0700
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
<https://learn.microsoft.com/en-us/DeployEdge/edge-learnmore-rollback> 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 <aga...@tracelink.com>: Mar 18 01:53AM -0700
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 ?
On Tuesday, March 18, 2025 at 9:57:14 AM UTC+5:30 ke...@kevinlocke.name
wrote:
|
Zoltán Lehóczky <pyroc...@gmail.com>: Mar 18 09:52AM -0700
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).
|