selenium: [🐛 Bug]: [rb]: Debug logger initialize gives "wrong number of arguments"

What happened?

All our tests fail for the new selenium version 4.9.1 (See https://github.com/dodona-edu/dodona/pull/4619)

I traced to root cause to changes made in https://github.com/SeleniumHQ/selenium/commit/1cd84f7b6bf6b45b05371710d2d6eb7cc5631f35

Changing this line https://github.com/SeleniumHQ/selenium/blob/c6f7396f62d02932be0fc3b54846dca12bfa43a6/rb/lib/selenium/webdriver.rb#LL99C42-L99C42 from:

@logger ||= WebDriver::Logger.new('Selenium', default_level: level, **opts)

@logger ||= WebDriver::Logger.new(progname: 'Selenium', default_level: level, **opts)

Fixes the issue

How can we reproduce the issue?

Running any of our tests here https://github.com/dodona-edu/dodona/pull/4619 should reproduce.

I am sorry for not making a smaller example, but I think it would fail in almost any example...

Relevant log output

/home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver/common/logger.rb:51:in `initialize': wrong number of arguments (given 2, expected 0..1) (ArgumentError)
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/capybara-3.39.0/lib/capybara/selenium/logger_suppressor.rb:8:in `initialize'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver.rb:99:in `new'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver.rb:99:in `logger'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver/common/service_manager.rb:81:in `build_process'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver/common/service_manager.rb:103:in `start_process'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver/common/service_manager.rb:57:in `block in start'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver/common/socket_lock.rb:42:in `locked'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver/common/service_manager.rb:55:in `start'
	  from <internal:kernel>:90:in `tap'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver/common/service.rb:91:in `launch'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver/common/driver.rb:334:in `service_url'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver/common/local_driver.rb:28:in `initialize_local_driver'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver/chrome/driver.rb:34:in `initialize'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver/common/driver.rb:47:in `new'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver/common/driver.rb:47:in `for'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.9.1/lib/selenium/webdriver.rb:88:in `for'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/capybara-3.39.0/lib/capybara/selenium/driver.rb:83:in `browser'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/capybara-3.39.0/lib/capybara/selenium/driver.rb:104:in `visit'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/capybara-3.39.0/lib/capybara/session.rb:280:in `visit'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/capybara-3.39.0/lib/capybara/dsl.rb:52:in `call'
	  from /home/jorg/.rvm/gems/ruby-3.1.2/gems/capybara-3.39.0/lib/capybara/dsl.rb:52:in `visit'

Operating System

Linux mint

Selenium version

4.9.1

What are the browser(s) and version(s) where you see this issue?

Not using a browser

What are the browser driver(s) and version(s) where you see this issue?

ChromeDriver 111.0.5563.64

Are you using Selenium Grid?

No response

About this issue

Original URL
State: closed
Created a year ago
Reactions: 4
Comments: 17 (7 by maintainers)

Commits related to this issue

Fix selenium-webdriver version to avoid bug As a temporary workaround, we're fixing selenium-webdriver to v4.9.0 to avoid being hit by https://github.com/SeleniumHQ/selenium/issues/12005. — committed to solidusio/solidus by waiting-for-dev a year ago
Fix selenium-webdriver version to avoid bug As a temporary workaround, we're fixing selenium-webdriver to v4.9.0 to avoid being hit by https://github.com/SeleniumHQ/selenium/issues/12005. [skip ci] — committed to solidusio/solidus by waiting-for-dev a year ago
Fix selenium-webdriver version to avoid bug As a temporary workaround, we're fixing selenium-webdriver to v4.9.0 to avoid being hit by https://github.com/SeleniumHQ/selenium/issues/12005. [skip ci] — committed to solidusio/solidus by waiting-for-dev a year ago
chore: temporarily pin selenium-webdriver to 4.9.0 https://github.com/SeleniumHQ/selenium/issues/12005 — committed to ViewComponent/lookbook by allmarkedup a year ago
chore: temporarily pin selenium-webdriver to 4.9.0 https://github.com/SeleniumHQ/selenium/issues/12005 — committed to ViewComponent/lookbook by allmarkedup a year ago
Revert "Fix selenium-webdriver version to avoid bug" This reverts commit f468994c3ececb2c1b1cd1d3d5b33f31f3c800b5. After the release of capybara 3.39.1 with a fix for the issue for the newest seleni... — committed to nebulab/solidus by waiting-for-dev a year ago
Revert "Fix selenium-webdriver version to avoid bug" This reverts commit 9224baf44ebbff9daf47490dbb7f4a2a62a46e27. After the release of capybara 3.39.1 with a fix for the issue for the newest seleni... — committed to nebulab/solidus by waiting-for-dev a year ago

Most upvoted comments

Fork the repo, create your own branch and merge whatever and make a PR with it. Worst case he decides to go a different way (essentially what happened with the PR I made). 😃

Just getting in the habit of proposing actual code instead of just raising issues makes a huge difference over time. Open source code is “ours,” not “theirs.”

titusfortner on May 12, 2023

Please, let us know if we should move the conversation to the Capybara issue. For now, I’ll keep it here as @twalpole has been tagged, and they can tell us the best thing to do.

We were thinking of backporting the bug fix to the latest stable branch and submitting a PR there. However, we realized there’s no 3.39_stable branch; instead, the “last” one is 3.38_stable. As we can’t create the branch in the repository, we’ll happily create the PR if the branch is created. Probably, that would be the best thing to do. A minor release probably needs more considerations, but being a bug fix, a patch release should be enough.

Please, let us know if we can help in any other way, and thanks for your support on this.

waiting-for-dev on May 11, 2023

Managing a group of gems is a lot of hassle regardless. Not much to do here in the short term. Long term big picture, finding popular but under resourced open source projects and contributing to them enough to be entrusted with the ability to release them would make a huge difference to the ecosystem.

titusfortner on May 11, 2023

Some people I can’t get to be bothered to update off of 5 year old versions. Some people can’t stand not to always have the absolute latest versions. 😂

Capybara is a large open source project with a single unpaid maintainer. He’ll get to a release when it is convenient for him to do so. The stakes are pretty low on this one. Just limit the version in your gemspec for now.

titusfortner on May 11, 2023