Chrome Driver Reset Sessions returns NoMethodError if all window_handles are gone
broksonic21 opened this issue · comments
Meta
Capybara Version: 3.39.2
Driver Information (and browser if relevant): selenium-webdriver 4.9.0 with chrome
Expected Behavior
We are not 100% positive of why we get into this state, but the chrome driver returns a NoMethodError from "window_handles.first" in reset_sessions if "window_handles" is nil for any reason. Can it be changed to better handle this case?
Expectation is it checks for nil and resets the session or something, or at least, doesn't error as a no-op.
Actual Behavior
Seems to come from here which isn't checking for nil:
NoMethodError: NoMethodError: undefined method `first' for nil:NilClass
Steps to reproduce
We run into this irregularly, so hard to have an exact reproduction, but the code at issue is obvious
NoMethodError: NoMethodError: undefined method `first' for nil:NilClass
/usr/local/bundle/gems/capybara-3.39.2/lib/capybara/selenium/driver_specializations/chrome_driver.rb:40:in `reset!'
/usr/local/bundle/gems/capybara-3.39.2/lib/capybara/session.rb:131:in `reset!'
/usr/local/bundle/gems/capybara-3.39.2/lib/capybara.rb:327:in `block in reset_sessions!'
/usr/local/bundle/gems/capybara-3.39.2/lib/capybara.rb:327:in `reverse_each'
/usr/local/bundle/gems/capybara-3.39.2/lib/capybara.rb:327:in `reset_sessions!'
I'm wondering how you managed to close all the windows, since the driver is meant to prevent that. Are you modifying the window handles/sessions directly? If so it's on you to manage them.
Actually this is even worse --- how are you getting window_handles to be nil??? I think for that to happen would require the connection to chromedriver to have been broken, which won't be recoverable. Don't really think there's anything we can do here
To be honest, not sure how we got into this state. This is part of a large test bed with a number of developers, and I’d say about a number of builds per day had been showing this error - not a high %, but enough to be noticeable and annoying. Always at different spots or tests, and rerunning always fixed it up.
Definitely something flaky causes it, but hard to track down, and I wouldn’t expect capybara to fail in this state, as it can (and does happen). Perhaps a chrome crash?
To help mitigate, I changed our calling code to check if current_session.driver.window_handles.present?, and if so, call current_session.quit instead of current_session.reset_session!
This seems to have helped a lot - we haven’t seen any issues since. After the quit call, capybara tries to recreate itself and that seems to be working well.
Just wanted to chime in and say that I've seen also similar errors. I do page.windows.filter { |window| window != page.current_window }.each(&:close) in config.append_after :each which sometimes (very rarely) blows up similarly - again probably due to flaky tests - but as @broksonic21 says, it would be nice if Capybara handles that gracefully.