Chrome 137 does not render modals causing tests to fail.

[Eeyurrn]

Our test suite is having a problem with Google Chrome version 137.

Modals are not rendering on the page causing accept_confirm calls to fail. Below is an example of the error we are getting.

Similar errors occur with dismiss_confirm.

However if we keep the Chrome version at 136, the tests pass and there is no problem. While we can keep the Chrome version pinned to 136, it's not a great solution as we want to test against more recent versions of Chrome.

Failures:

  1) Extraction: navigating using the keyboard de & qa templates exist can navigate through fields with keyboard shortcuts
     Failure/Error:
       accept_confirm do
         click_link "Back"
       end

     Capybara::ModalNotFound:
       Unable to find modal dialog

We are currently running the tests with RSpec, using the Selenium driver.

gem versions

capybara: 3.40.0
selenium-webdriver: 4.33.0

Seeing as Chrome 137 was released May 27, 2025 it seems that having the latest versions of capybara and webdriver may not be much help.

Here are the webdriver options for Chrome

    options = Selenium::WebDriver::Chrome::Options.new(unhandled_prompt_behavior: :ignore)
    options.web_socket_url = true
    options.add_preference(:download, prompt_for_download: false, default_directory: DOWNLOADS_PATHNAME.to_s)
    options.add_preference(:browser, set_download_behavior: {behavior: "allow"})
    options.browser_name = "chrome"
    # v137.0.7151.55 fails at detecting modals, so let's stick to v136 for now
    options.browser_version = "137"
    options.add_argument("window-size=#{default_size[:width]},#{default_size[:height]}")
    options.add_argument("disable-web-security")   # disable CORS in tests
    options.add_argument("disable-popup-blocking") # disable the chrome popup warning about leaving a page with unsaved data
    options.add_argument("no-sandbox")
    options.add_argument("enable-features=NetworkService,NetworkServiceInProcess")
    options.add_argument("whitelisted-ips='127.0.0.1'")


    # Stop the chrome browser querying the google servers for optimisation hints etc.. for
    # every tab that chrome opens.
    options.add_argument("--disable-features=OptimizationGuideModelDownloading,OptimizationHintsFetching,OptimizationTargetPrediction,OptimizationHints")

I'm not sure if this is a problem with Capybara, but I decided to post the issue here to get the team's attention.

Thanks for your help!

[bryanyee]

I'm having similar issues too, with dismissible banners not appearing. However we only encountered the errors in our CodeShip CI environment, but not when using Chrome 137 on a local Mac. We're temporarily working around the issue by locking down to Chrome 136 in CI.

Just to provide more context for others, @Eeyurrn what environment are you encountering the failures in?

[Eeyurrn]

@bryanyee We run our CI on BuildKite via docker compose. I can also reproduce the failures on my local Mac. The browser I used locally is Chrome for Testing.

[Eeyurrn]

@bryanyee I've done some further investigation on this and have isolated it to just the modal that appears when you want to leave the page, if you have unsaved work.

This is triggered by the browser's beforeunload event.

  window.addEventListener('beforeunload', function(event){
    event.preventDefault();
    event.returnValue = false;
  });

Other modals triggered by window.confirm() work in the test environment, it's the ones triggered by the beforeunload that cannot be picked up by Capybara/Selenium/Chromedriver

Have you made any progress?

[twalpole]

@Eeyurrn That is being specifically disabled in the OPs config

 options.add_argument("disable-popup-blocking") # disable the chrome popup warning about leaving a page with unsaved data

[twalpole]

Since Capybaras alert modals tests pass against the latest chrome (138) I assume this was an issue with chrome 137/webdriver 137 --- closing for now. If still experiencing with 138 (and it being about the modal which is specifically disabled in the config) we can reopen

[Eeyurrn]

@twalpole Thanks for looking at this.

I have run this using a minimal test case on Chrome 138 and removing the options.add_argument("disable-popup-blocking") and it still fails, specifically on the dialog raised by the beforeunload event.

[Osseta]

For those following along I have created a new ticket which has a PR with a reproduction case in it.

new issue: #2824
PR: #2823