Explicitly specifying the chromedriver binary path during WebDriver instantiation leads to timeouts

[John Trupiano]

When I explicitly set the binary path to my chromedriver during driver instantiation as such....

    options = Selenium::WebDriver::Chrome::Options.new(

      binary: File.expand_path('~/bin/chromedriver')

    )

    driver = Selenium::WebDriver.for :chrome, options: options

    driver.get fixture_path(fixture_filename) if !fixture_filename.nil?

....my code hangs (and ultimately times out) in net/http.

Error: Net::ReadTimeout: Net::ReadTimeout

/Users/me/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/net/protocol.rb:176:in `rbuf_fill'

/Users/me/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/net/protocol.rb:154:in `readuntil'

/Users/me/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/net/protocol.rb:164:in `readline'

/Users/me/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/net/http/response.rb:40:in `read_status_line'

/Users/me/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/net/http/response.rb:29:in `read_new'

/Users/me/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/net/http.rb:1446:in `block in transport_request'

/Users/me/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/net/http.rb:1443:in `catch'

/Users/me/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/net/http.rb:1443:in `transport_request'

/Users/me/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/net/http.rb:1416:in `request'

/Users/me/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/net/http.rb:1409:in `block in request'

/Users/me/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/net/http.rb:877:in `start'

/Users/me/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/net/http.rb:1407:in `request'

/Users/me/.rvm/gems/ruby-2.4.1@proj/gems/selenium-webdriver-3.6.0/lib/selenium/webdriver/remote/http/default.rb:123:in `response_for'

/Users/me/.rvm/gems/ruby-2.4.1@proj/gems/selenium-webdriver-3.6.0/lib/selenium/webdriver/remote/http/default.rb:78:in `request'

/Users/me/.rvm/gems/ruby-2.4.1@proj/gems/selenium-webdriver-3.6.0/lib/selenium/webdriver/remote/http/common.rb:61:in `call'

/Users/me/.rvm/gems/ruby-2.4.1@proj/gems/selenium-webdriver-3.6.0/lib/selenium/webdriver/remote/bridge.rb:170:in `execute'

/Users/me/.rvm/gems/ruby-2.4.1@proj/gems/selenium-webdriver-3.6.0/lib/selenium/webdriver/remote/bridge.rb:103:in `create_session'

/Users/me/.rvm/gems/ruby-2.4.1@proj/gems/selenium-webdriver-3.6.0/lib/selenium/webdriver/remote/bridge.rb:54:in `handshake'

/Users/me/.rvm/gems/ruby-2.4.1@proj/gems/selenium-webdriver-3.6.0/lib/selenium/webdriver/chrome/driver.rb:58:in `initialize'

/Users/me/.rvm/gems/ruby-2.4.1@proj/gems/selenium-webdriver-3.6.0/lib/selenium/webdriver/common/driver.rb:46:in `new'

/Users/me/.rvm/gems/ruby-2.4.1@proj/gems/selenium-webdriver-3.6.0/lib/selenium/webdriver/common/driver.rb:46:in `for'

/Users/me/.rvm/gems/ruby-2.4.1@proj/gems/selenium-webdriver-3.6.0/lib/selenium/webdriver.rb:86:in `for'

However, if I don't specify the binary path (allowing the chromedriver executable to be found on my $PATH), my code runs just fine.  My first suspicion was that I must have two different chromedriver's installed on my system.  But that does not appear to be the case:

ruby-2.4.1@proj ~/projects/proj (ruby2.4) $> mv ~/bin/chromedriver ~/bin/not_chromedriver

ruby-2.4.1@proj ~/projects/proj (ruby2.4) $> which chromedriver

ruby-2.4.1@proj ~/projects/proj (ruby2.4) $> mv ~/bin/not_chromedriver ~/bin/chromedriver

ruby-2.4.1@proj ~/projects/proj (ruby2.4) $> which chromedriver

/Users/me/bin/chromedriver

This code is running on my local machine.  It's being run as my own user.  I'm really struggling to understand how/why there would be any difference in behavior.

Where in the codebase can/should I be looking to verify exactly how chromedriver is being invoked.  It must be being invoked differently in these two scenarios, no?  Can one of y'all point me in the right direction?

Thanks,

John

[John Trupiano]

Figured out the issue.  Options#binary is used to specify the location of your Chrome binary, NOT the chromedriver binary.

selenium/webdriver hangs somewhere in net/http when chromedriver cannot find your Chrome binary, which made this hard to troubleshoot.

-John