Selenium 4: Ruby bindings

[p0deje]

This PR is opened for the list of changes I'd like to do for Ruby bindings in Selenium 4. Please read below for details and I'll be happy to hear the feedback. Let's have this PR both as To Do list and discussion board + code of what we want to see in Selenium 4. I'll be updating the list throughout the implementation and discussion.

I'll be very happy to hear the feedback from everyone else involved in selenium-webdriver gem development (@titusfortner, @lmtierney, @twalpole). If something is not clear or doesn't make any sense or causes trouble for higher-level libraries (Watir, Capybara) - let's discuss here.

Removal of OSS dialect

• Remove deprecated Mouse class.
• Remove deprecated Keyboard class.
• Remove all OSS -> W3C capabilities conversion and aliases.
• Convert all W3CSometimg classes to Something. Remove their OSS equivalents.
• Change API for timeouts.
• Remove protocol handshake.
• Rename desired_capabilities to capabilities and provide W3C-compliant API for setting then (alwaysMatch, firstMatch).

Cleanup

• Remove Firefox legacy driver support.
• Remove PhantomJS code (or extract to standalone gem) (?).
• Go through all the driver extensions and drop the ones that no longer make any sense.

Improvements

• Implement automatic driver extensions loading based on returned capabilities (it should have been there all the time).
• Implement Safari::Options.
• Implement Edge::Options.
• Allow to pass Options classes to remote instances.
• Allow to pass custom Service instances to driver in favor of driver_opts. Deprecate driver_opts. (?)
• Use element/{element id}/attribute/{name} to get element instead of atom (confirm with Simon).

Ruby-specific

• Deprecate Selenium::WebDriver namespace in favor of Selenium. (?)
• Require minimum Ruby version to 2.3 (EOL is in March) (https://www.ruby-lang.org/en/downloads/branches/).
• Address all C-rb issues (somehow).
• Address all C-rb pull requests (somehow).
• Remove JRuby-specific SocketPoller#listening? as the bug it works around has been fixed in JRuby 1.6.7 (http://jruby.org/2012/02/22/jruby-1-6-7).
• Remove any custom code that checks for defined RUBY_ENGINE as it was only undefined in MRI 1.8 (also search for similar constants).
• Check if we still need custom logic for getting HOME directory on JRuby.
• Remove anything related to IronRuby - it’s not developed anymore.
• Simplify Platform#null_device as File::NULL was introduced in Ruby 1.9.3 (https://svn.ruby-lang.org/repos/ruby/tags/v1_9_3_0/NEWS).
• Drop all the execution via $PROGRAM_NAME == __FILE__ - use IRB instead.
• Properly handle Windows/Unix path separators using File::ALT_SEPARATOR whenever possible.
• Remove all the compatibility layer for old Ruby in Logger .
• Remove PortProber.random as it should be avoided (deprecated in 6d3edb5).
• Rework Wait to use Process::CLOCK_MONOTONIC instead of Time as the latter is often monkey-patched (e.g. Timecop).
• Deprecate and extract all custom HTTP clients (curb/persistent) (?).
• Go through YARD docs and add missing.
• Use safe-navigation operator where needed (&.)

---

This change is 

[twalpole]

This all sounds fine to me other than the deprecating of the Selenium::WebDriver namespace - that's going to make exception handling while supporting selenium-webdriver 3 and 4 in Capybara a pain

[twalpole]

This all sounds fine to me other than the deprecating of the Selenium::WebDriver namespace - that's going to make exception handling while supporting selenium-webdriver 3 and 4 in Capybara a pain

[p0deje]

This all sounds fine to me other than the deprecating of the Selenium::WebDriver namespace - that's going to make exception handling while supporting selenium-webdriver 3 and 4 in Capybara a pain

Fair enough. We might just not do that or find a way to make it work for Capybara painlessly. @titusfortner proposed this, so maybe he has an opinion on that.

[p0deje]

This all sounds fine to me other than the deprecating of the Selenium::WebDriver namespace - that's going to make exception handling while supporting selenium-webdriver 3 and 4 in Capybara a pain

Fair enough. We might just not do that or find a way to make it work for Capybara painlessly. @titusfortner proposed this, so maybe he has an opinion on that.