Chrome 134 breaks Selenium tests - intermittent failures with visit(visit_uri)

[MatzFan]

My test suite runs fine with Chrome 133 (Selenium 4.29.0-20250222).

Upgrading to Chrome 134 (Selenium 4.29.0-20250303) results in intermittent failures due to the session's path not updating after a call to Capybara::Session#visit. In isolating the problem I did something like this:

...
visit '/foo/bar'
puts page.current_path # => '/' - i.e. path not updated
...

I've temporarily fixed the problem with a workaround which overrides Capybara::Session#visit like so in my test helper:

def visit(url)
    10.times do
      Capybara.current_session.visit url
      return if page.current_path == url

      sleep 0.1
    end
    abort 'Capybara::Session#visit broken after 1 second wait'
  end

Happy to provide a MRE if this is not a known problem.

Note this does not appear to be duplicate of #2793 as the problem is not observed with Chrome 133.

Ruby 3.4.2
Capybara 3.40.0
selenium-webdriver 4.29.1 (in Docker container)
OS: LMDE faye (based on Debian bookworm)

[BlakeGardner]

I'm experiencing the same issue.

I downgraded the following and all of my builds still fail, which makes me suspect there is a sub dependency that is causing the issue somewhere.

• capybara
• selenium-webdriver
• Chrome
• The Github workflow runner (tested ubuntu-22.04 and ubuntu-latest

I even tried to run a build from many weeks ago and that fails with the same errors.

[faelsoto]

It's not only visit, we've been finding that every interaction that involves a page load will fail due to the browser not waiting for the next page load.

For example, this will fail:

assert_difference -> { Account.count } do
  click_button "Sign up"
end

[benalavi]

We're seeing this too. In our case we've only seen it w/ clicks that submit a form. It also seems to be a race condition as to whether the click will return immediately or wait for navigation. The browser still waits for the page to load, so if the next action is another action that uses the browser (another click_on, has_content? ..., etc) then things will still work as the next action will still have to wait for the page to load from the previous click. However if the next action does something outside of the browser (like check the DB, Account.count in the example above), and click_on returned immediately then the action might happen before the next page load.

We can work around the issue by checking for a result in the browser after the form submission, before checking for side effects, but it's still surprising to have inconsistent behavior.

We can make it very obvious by adding something like sleep 5 to the route handler, then we can see the click_on sometimes return after 5s and other times return immediately.

We're using Selenium and Chromedriver and these are the logs of the click w/ a 5s delay:

selenium

2025-03-14 15:18:52 DEBUG Selenium [:command] -> POST session/faa1e3e078d1ec72a9223ae77b4cf4c5/element/f.1320DB0BC7087CA385C0B8D07C31977E.d.641C2A4E3A8AED4C38CDA2CE45316E7C.e.59/click 
2025-03-14 15:18:57 DEBUG Selenium [:header]    <<<  {"content-length"=>["14"], "content-type"=>["application/json; charset=utf-8"], "cache-control"=>["no-cache"]} 
2025-03-14 15:18:57 DEBUG Selenium [:command] <- {"value":null} 

chromedriver

[03-14-2025 15:18:52.307431][INFO]: [faa1e3e078d1ec72a9223ae77b4cf4c5] COMMAND ClickElement {
   "id": "f.1320DB0BC7087CA385C0B8D07C31977E.d.641C2A4E3A8AED4C38CDA2CE45316E7C.e.59"
}
[03-14-2025 15:18:52.307472][INFO]: Waiting for pending navigations...
[03-14-2025 15:18:52.307881][INFO]: Done waiting for pending navigations. Status: ok
[03-14-2025 15:18:52.341655][INFO]: Waiting for pending navigations...
[03-14-2025 15:18:57.504210][INFO]: Done waiting for pending navigations. Status: ok
[03-14-2025 15:18:57.504354][INFO]: [faa1e3e078d1ec72a9223ae77b4cf4c5] RESPONSE ClickElement

...and these are the logs when it returns immediately:

selenium

2025-03-14 15:17:28 DEBUG Selenium [:command] -> POST session/9e2f02a196c30375806e6b7b2b547382/element/f.6CEA5FEDD794621E4A99DCAF55FB1F49.d.905E6E26A4B9B078C5A6ED2D5EDF03B7.e.59/click 
2025-03-14 15:17:29 DEBUG Selenium [:header]    <<<  {"content-length"=>["14"], "content-type"=>["application/json; charset=utf-8"], "cache-control"=>["no-cache"]} 
2025-03-14 15:17:29 DEBUG Selenium [:command] <- {"value":null} 

chromium

[03-14-2025 15:17:28.968841][INFO]: [9e2f02a196c30375806e6b7b2b547382] COMMAND ClickElement {
   "id": "f.6CEA5FEDD794621E4A99DCAF55FB1F49.d.905E6E26A4B9B078C5A6ED2D5EDF03B7.e.59"
}
[03-14-2025 15:17:28.968896][INFO]: Waiting for pending navigations...
[03-14-2025 15:17:28.969347][INFO]: Done waiting for pending navigations. Status: ok
[03-14-2025 15:17:29.000385][INFO]: Waiting for pending navigations...
[03-14-2025 15:17:29.000834][INFO]: Done waiting for pending navigations. Status: ok
[03-14-2025 15:17:29.000899][INFO]: [9e2f02a196c30375806e6b7b2b547382] RESPONSE ClickElement

...based on those my guess is that the race is in Chrome or Chromedriver and Capybara/Selenium may not be responsible for waiting for navigation after the click.

EDIT: Possibly related bug report for Chrome/Chromedriver: https://issues.chromium.org/issues/402796660

[zrlstone]

Also experiencing the issue since Chrome 133, capybara (3.40.0), selenium-webdriver (4.29.0)
Example:

    visit root_path
    click_link "Create New user"

    fill_in "new_user_form[first_name]", with: "Test"

    click_on 'Save'

    @user = User.find_by(first_name: 'Test')

    visit user_path(@user)

Results in an intermittent failure when finding the record (i.e. an action outside the browser as mentioned above)

  Failure/Error: visit user_path(@customer)

     ActionController::UrlGenerationError:
       No route matches {:action=>"show", :controller=>"users", :id=>nil}, missing required keys: [:id]

Adding a matcher, for exampleexpect(page).to have_content "New user created after the click_on gets the spec passing, but not practical for a large test suite. The override for Capybara::Session#visit is useful, thanks @MatzFan. I've been trying create a patch for the click method without much luck.

[javierm]

(Not sure this is really a Capybara issue, but since people might find this thread while looking for information, might as well comment here.)

We're experiencing the same issue. As mentioned earlier, downgrading Chromium/Chromedriver didn't solve the issue, and we didn't change anything in pull requests that were previously passing, so I guess there's been a different change in GitHub Actions (which we use to run the tests) 🤔.

We've removed the few database calls we had, like the mentioned .count or .find_by, after starting the browser with a visit in the tests. In some cases, we've seen that there were ambiguous expectations (content we checked after doing an action was already present before that action). However, we're still getting a dozen apparently random failures on every test run, and in many cases we couldn't find anything wrong with either the failing test or the tests that were executed before the one which failed.

[axlekb]

I found #2796 was helpful in solving our Chrome 134 related issues:

Specifically adding

browser_options.add_argument 'disable-backgrounding-occluded-windows'

[javierm]

@benalavi Thanks a lot for the info! 🙏 We didn't want to add a sleep 5 call after every call to click_button, so for now we're having some success with this incredibly ugly patch. Ideas for simplifications are welcome!

module Capybara
  module DSL
    def click_button_and_check_path(...)
      path = current_path

      original_click_button(...)

      page.has_no_current_path?(path)
    end

    alias_method :original_click_button, :click_button
    def click_button(*, check_path: true, **)
      if check_path
        click_button_and_check_path(*, **)
      else
        original_click_button(*, **)
      end
    end

    alias_method :original_accept_confirm, :accept_confirm
    def accept_confirm(...)
      define_singleton_method :click_button do |*args, **kw|
        original_click_button(*args, **kw)
      end

      original_accept_confirm(...)

      define_singleton_method :click_button do |*args, **kw|
        click_button_and_check_path(*args, **kw)
      end
    end

    alias_method :original_dismiss_confirm, :dismiss_confirm
    def dismiss_confirm(...)
      define_singleton_method :click_button do |*args, **kw|
        original_click_button(*args, **kw)
      end

      original_dismiss_confirm(...)

      define_singleton_method :click_button do |*args, **kw|
        click_button_and_check_path(*args, **kw)
      end
    end
  end
end

Basically, what this does:

1. It monkey-patches click_button so it checks the path has changed after clicking a button but, since we've got dozens of tests where that's not the case (AJAX calls, validation errors in forms, ...), we're using has_no_current_path? instead of expect(page).not_to have_current_path.
2. It disables the monkey-patch when clicking buttons that result in modal dialogs; otherwise, the test will fail.
3. It adds an optional argument to click_button so we can opt out of checking the path in a couple of specs checking unusual situations.

@axlekb Thanks for the suggestion! Unfortunately, adding those options didn't work in our case 🤔.

[simi]

I have seen the same recently. Following Capybara setup made it fixed. --no-sandbox seems crucial to me.

Capybara.register_driver :selenium_chrome_headless do |app|
  version = Capybara::Selenium::Driver.load_selenium
  options_key = Capybara::Selenium::Driver::CAPS_VERSION.satisfied_by?(version) ? :capabilities : :options
  browser_options = Selenium::WebDriver::Chrome::Options.new.tap do |opts|
    opts.add_argument('--headless')
    opts.add_argument('--no-sandbox')
    opts.add_argument('--window-size=1280,1024')
  end

  Capybara::Selenium::Driver.new(app, **{:browser => :chrome, options_key => browser_options})
end

Capybara.javascript_driver = :selenium_chrome_headless

[pixeltrix]

The underlying cause seems to be errors like this:

Selenium::WebDriver::Error::UnknownError:
  unknown error: unhandled inspector error: {
    "code":-32000,"message":"Node with given id does not belong to the document"
  }

Depending on your code these can get swallowed up and failures manifest themselves in a variety of ways - for example I thought WebMock was failing with missing stubs but it was a request from the previous spec leaking into the next spec before stubs had been set. Similarly expecting on database records fails with not found errors or nil references.

Searching around I've seen some comments about the window handles list now contains the dev tools window and wonder whether the unhandled inspector error is a possible hint. In the meantime, it's a hack, but adding Selenium::WebDriver::Error::UnknownError to the list of invalid element errors seems to help with our system specs

RSpec.configure do |config|
  config.before type: :system do |example|
    if page.driver.respond_to?(:invalid_element_errors)
      unless page.driver.invalid_element_errors.include?(Selenium::WebDriver::Error::UnknownError)
        page.driver.invalid_element_errors << Selenium::WebDriver::Error::UnknownError
      end
    end
  end
end