capybara 3.13.2 → 3.40.0

data/README.md

@@ -1,12 +1,8 @@
 # Capybara
 
-[![Build Status](https://secure.travis-ci.org/teamcapybara/capybara.svg)](https://travis-ci.org/teamcapybara/capybara)
-[![Build Status](https://ci.appveyor.com/api/projects/status/github/teamcapybara/capybara?svg=true)](https://ci.appveyor.com/api/projects/github/teamcapybara/capybara)
+[![Build Status](https://github.com/teamcapybara/capybara/actions/workflows/build.yml/badge.svg)](https://github.com/teamcapybara/capybara/actions/workflows/build.yml)
 [![Code Climate](https://codeclimate.com/github/teamcapybara/capybara.svg)](https://codeclimate.com/github/teamcapybara/capybara)
-[![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/jnicklas/capybara?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
-[![SemVer](https://api.dependabot.com/badges/compatibility_score?dependency-name=capybara&package-manager=bundler&version-scheme=semver)](https://dependabot.com/compatibility-score.html?dependency-name=capybara&package-manager=bundler&version-scheme=semver)
-
-**Note** You are viewing the README for the version 3.13.x of Capybara.
+[![Coverage Status](https://coveralls.io/repos/github/teamcapybara/capybara/badge.svg?branch=master)](https://coveralls.io/github/teamcapybara/capybara?branch=master)
 
 Capybara helps you test web applications by simulating how a real user would
 interact with your app. It is agnostic about the driver running your tests and
@@ -19,8 +15,7 @@ If you and/or your company find value in Capybara and would like to contribute f
 <a href="https://www.patreon.com/capybara">Patreon</a>
 
 
-**Need help?** Ask on the mailing list (please do not open an issue on
-GitHub): http://groups.google.com/group/ruby-capybara
+**Need help?** Ask on the discussions (please do not open an issue): https://github.com/orgs/teamcapybara/discussions/categories/q-a
 
 ## Table of contents
 
@@ -35,9 +30,6 @@ GitHub): http://groups.google.com/group/ruby-capybara
     - [Selecting the Driver](#selecting-the-driver)
     - [RackTest](#racktest)
     - [Selenium](#selenium)
-    - [Apparition](#apparition)
-    - [Capybara-webkit](#capybara-webkit)
-    - [Poltergeist](#poltergeist)
 - [The DSL](#the-dsl)
     - [Navigating](#navigating)
     - [Clicking links and buttons](#clicking-links-and-buttons)
@@ -49,6 +41,10 @@ GitHub): http://groups.google.com/group/ruby-capybara
     - [Scripting](#scripting)
     - [Modals](#modals)
     - [Debugging](#debugging)
+- [Selectors](#selectors)
+    - [Name](#selectors-name)
+    - [Locator](#selectors-locator)
+    - [Filters](#selectors-filters)
 - [Matching](#matching)
     - [Exactness](#exactness)
     - [Strategy](#strategy)
@@ -57,11 +53,13 @@ GitHub): http://groups.google.com/group/ruby-capybara
 - [Using the DSL elsewhere](#using-the-dsl-elsewhere)
 - [Calling remote servers](#calling-remote-servers)
 - [Using sessions](#using-sessions)
+    - [Named sessions](#named-sessions)
+    - [Using sessions manually](#using-sessions-manually)
 - [XPath, CSS and selectors](#xpath-css-and-selectors)
 - [Beware the XPath // trap](#beware-the-xpath--trap)
 - [Configuring and adding drivers](#configuring-and-adding-drivers)
 - [Gotchas:](#gotchas)
-- ["Threadsafe" mode](#threadsafe)
+- ["Threadsafe" mode](#threadsafe-mode)
 - [Development](#development)
 
 ## <a name="key-benefits"></a>Key benefits
@@ -75,7 +73,7 @@ GitHub): http://groups.google.com/group/ruby-capybara
 
 ## <a name="setup"></a>Setup
 
-Capybara requires Ruby 2.3.0 or later. To install, add this line to your
+Capybara requires Ruby 3.0.0 or later. To install, add this line to your
 `Gemfile` and run `bundle install`:
 
 ```ruby
@@ -146,11 +144,13 @@ Load RSpec 3.5+ support by adding the following line (typically to your
 require 'capybara/rspec'
 ```
 
-If you are using Rails, put your Capybara specs in `spec/features` or `spec/system` (only works
-if [you have it configured in
-RSpec](https://www.relishapp.com/rspec/rspec-rails/docs/upgrade#file-type-inference-disabled))
-and if you have your Capybara specs in a different directory, then tag the
-example groups with `type: :feature` or `type: :system` depending on which type of test you're writing.
+If you are using Rails, put your Capybara specs in `spec/features` or `spec/system` (only works if
+[you have it configured in RSpec](https://rspec.info/features/6-0/rspec-rails/directory-structure/))
+and if you have your Capybara specs in a different directory, then tag the example groups with
+`type: :feature` or `type: :system` depending on which type of test you're writing.
+
+If you are using Rails system specs please see [their documentation](https://rspec.info/features/6-0/rspec-rails/system-specs/system-specs)
+for selecting the driver you wish to use.
 
 If you are not using Rails, tag all the example groups in which you want to use
 Capybara with `type: :feature`.
@@ -160,7 +160,7 @@ You can now write your specs like so:
 ```ruby
 describe "the signin process", type: :feature do
   before :each do
-    User.make(email: 'user@example.com', password: 'password')
+    User.create(email: 'user@example.com', password: 'password')
   end
 
   it "signs me in" do
@@ -182,7 +182,7 @@ to one specific driver. For example:
 ```ruby
 describe 'some stuff which requires js', js: true do
   it 'will use the default js driver'
-  it 'will switch to one specific driver', driver: :webkit
+  it 'will switch to one specific driver', driver: :selenium
 end
 ```
 
@@ -191,7 +191,7 @@ Capybara also comes with a built in DSL for creating descriptive acceptance test
 ```ruby
 feature "Signing in" do
   background do
-    User.make(email: 'user@example.com', password: 'caplin')
+    User.create(email: 'user@example.com', password: 'caplin')
   end
 
   scenario "Signing in with correct credentials" do
@@ -204,7 +204,7 @@ feature "Signing in" do
     expect(page).to have_content 'Success'
   end
 
-  given(:other_user) { User.make(email: 'other@example.com', password: 'rous') }
+  given(:other_user) { User.create(email: 'other@example.com', password: 'rous') }
 
   scenario "Signing in as another user" do
     visit '/sessions/new'
@@ -259,7 +259,9 @@ end
 
 ## <a name="using-capybara-with-minitest"></a>Using Capybara with Minitest
 
-* If you are using Rails, add the following code in your `test_helper.rb`
+* If you are using Rails system tests please see their documentation for information on selecting the driver you wish to use.
+
+* If you are using Rails, but not using Rails system tests, add the following code in your `test_helper.rb`
     file to make Capybara available in all test cases deriving from
     `ActionDispatch::IntegrationTest`:
 
@@ -274,8 +276,7 @@ end
       include Capybara::Minitest::Assertions
 
       # Reset sessions and driver between tests
-      # Use super wherever this method is redefined in your individual test classes
-      def teardown
+      teardown do
         Capybara.reset_sessions!
         Capybara.use_default_driver
       end
@@ -334,15 +335,15 @@ By default, Capybara uses the `:rack_test` driver, which is fast but limited: it
 does not support JavaScript, nor is it able to access HTTP resources outside of
 your Rack application, such as remote APIs and OAuth services. To get around
 these limitations, you can set up a different default driver for your features.
-For example if you'd prefer to run everything in Selenium, you could do:
+For example, if you'd prefer to run everything in Selenium, you could do:
 
 ```ruby
 Capybara.default_driver = :selenium # :selenium_chrome and :selenium_chrome_headless are also registered
 ```
 
-However, if you are using RSpec or Cucumber, you may instead want to consider
-leaving the faster `:rack_test` as the __default_driver__, and marking only those
-tests that require a JavaScript-capable driver using `js: true` or
+However, if you are using RSpec or Cucumber (and your app runs correctly without JS),
+you may instead want to consider leaving the faster `:rack_test` as the __default_driver__, and
+marking only those tests that require a JavaScript-capable driver using `js: true` or
 `@javascript`, respectively.  By default, JavaScript tests are run using the
 `:selenium` driver. You can change this by setting
 `Capybara.javascript_driver`.
@@ -351,7 +352,7 @@ You can also change the driver temporarily (typically in the Before/setup and
 After/teardown blocks):
 
 ```ruby
-Capybara.current_driver = :webkit # temporarily select different driver
+Capybara.current_driver = :selenium # temporarily select different driver
 # tests here
 Capybara.use_default_driver       # switch back to default driver
 ```
@@ -391,7 +392,7 @@ Capybara supports [Selenium 3.5+
 In order to use Selenium, you'll need to install the `selenium-webdriver` gem,
 and add it to your Gemfile if you're using bundler.
 
-Capybara pre-registers a number of named drives that use Selenium - they are:
+Capybara pre-registers a number of named drivers that use Selenium - they are:
 
   * :selenium                 => Selenium driving Firefox
   * :selenium_headless        => Selenium driving Firefox in a headless configuration
@@ -407,45 +408,6 @@ to the browsers.  See the section on adding and configuring drivers.
 same transaction as your tests, causing data not to be shared between your test
 and test server, see [Transactions and database setup](#transactions-and-database-setup) below.
 
-### <a name="apparition"></a>Apparition
-
-The [apparition driver](https://github.com/twalpole/apparition) in a new driver thatallows you to run tests using Chrome in a headless
-or headed configuration. It attempts to provide backwards compatibility with the [Poltergeist driver API](https://github.com/teampoltergeist/poltergeist)
-while allowing for the use of modern JS/CSS. It uses CDP to communicate with Chrome, thereby obviating the need for chromedriver.
-A compatibility layer for capybara-webkit is planned, although has not yet been started. This driver is being developed by the
-maintainer of Capybara and will attempt to keep up to date with new Capybara releases. It will probably be moved into the
-teamcapybara repo once completely stable.
-
-### <a name="capybara-webkit"></a>Capybara-webkit
-
-Note: `capybara-webkit` depends on QtWebkit which went EOL quite some time ago. There has been an attempt to revive the project but `capybara-webkit` is not yet (AFAIK) compatible with the revived version of QtWebKit (could be a good OSS project for someone) and as such is still limited to an old version of QtWebKit.  This means its support for modern JS and CSS is severely limited.
-
-The [capybara-webkit driver](https://github.com/thoughtbot/capybara-webkit) is for true headless
-testing. It uses QtWebKit to start a rendering engine process. It can execute JavaScript as well.
-It is significantly faster than drivers like Selenium since it does not load an entire browser.
-
-You can install it with:
-
-```bash
-gem install capybara-webkit
-```
-
-And you can use it by:
-
-```ruby
-Capybara.javascript_driver = :webkit
-```
-
-### <a name="poltergeist"></a>Poltergeist
-
-Note: `poltergeist` depends on PhantomJS for which active development ended quite some time ago (2.1.1). As such it is roughly equivalent to a 6-7 year old version of Safari, meaning lack of support for modern JS and CSS. If any effort to update PhantomJS succeeds in the future this situation could change.
-
-[Poltergeist](https://github.com/teampoltergeist/poltergeist) is another
-headless driver which integrates Capybara with
-[PhantomJS](http://phantomjs.org/). It is truly headless, so doesn't
-require Xvfb to run on your CI server. It will also detect and report
-any Javascript errors that happen within the page.
-
 ## <a name="the-dsl"></a>The DSL
 
 *A complete reference is available at
@@ -639,21 +601,31 @@ In drivers which support it, you can easily execute JavaScript:
 page.execute_script("$('body').empty()")
 ```
 
-For simple expressions, you can return the result of the script. Note
-that this may break with more complicated expressions:
+For simple expressions, you can return the result of the script.
 
 ```ruby
 result = page.evaluate_script('4 + 4');
 ```
 
+For more complicated scripts you'll need to write them as one expression.
+
+```ruby
+result = page.evaluate_script(<<~JS, 3, element)
+  (function(n, el){
+    var val = parseInt(el.value, 10);
+    return n+val;
+  })(arguments[0], arguments[1])
+JS
+```
+
 ### <a name="modals"></a>Modals
 
-In drivers which support it, you can accept, dismiss and respond to alerts, confirms and prompts.
+In drivers which support it, you can accept, dismiss and respond to alerts, confirms, and prompts.
 
-You can accept or dismiss alert messages by wrapping the code that produces an alert in a block:
+You can accept alert messages by wrapping the code that produces an alert in a block:
 
 ```ruby
-accept_alert do
+accept_alert 'optional text or regex' do
   click_link('Show Alert')
 end
 ```
@@ -661,7 +633,13 @@ end
 You can accept or dismiss a confirmation by wrapping it in a block, as well:
 
 ```ruby
-dismiss_confirm do
+accept_confirm 'optional text' do
+  click_link('Show Confirm')
+end
+```
+
+```ruby
+dismiss_confirm 'optional text' do
   click_link('Show Confirm')
 end
 ```
@@ -669,7 +647,13 @@ end
 You can accept or dismiss prompts as well, and also provide text to fill in for the response:
 
 ```ruby
-accept_prompt(with: 'Linus Torvalds') do
+accept_prompt('optional text', with: 'Linus Torvalds') do
+  click_link('Show Prompt About Linux')
+end
+```
+
+```ruby
+dismiss_prompt('optional text') do
   click_link('Show Prompt About Linux')
 end
 ```
@@ -719,6 +703,148 @@ Screenshots are saved to `Capybara.save_path`, relative to the app directory.
 If you have required `capybara/rails`, `Capybara.save_path` will default to
 `tmp/capybara`.
 
+## <a name="selectors"></a>Selectors
+
+Helpers and matchers that accept Selectors share a common method signature that
+includes:
+
+1. a positional Name argument
+2. a positional Locator argument
+3. keyword Filter arguments
+4. a predicate Filter block argument
+
+These arguments are usually optional in one way or another.
+
+### <a name="selectors-name"></a>Name
+
+The name argument determines the Selector to use. The argument is optional when
+a helper explicitly conveys the selector name (for example, [`find_field`][]
+uses `:field`, [`find_link`][] uses `:link`, etc):
+
+```ruby
+page.html # => '<a href="/">Home</a>'
+
+page.find(:link) == page.find_link
+
+page.html # => '<input>'
+
+page.find(:field) == page.find_field
+```
+
+### <a name="selectors-locator"></a>Locator
+
+The locator argument usually represents information that can most meaningfully
+distinguish an element that matches the selector from an element that does not:
+
+```ruby
+page.html # => '<div id="greeting">Hello world</div>'
+
+page.find(:css, 'div').text     # => 'Hello world'
+page.find(:xpath, './/div').text # => 'Hello world'
+```
+
+General purpose finder methods like [`find`][] and [`all`][] can accept the
+locator as their first positional argument when the method can infer the default
+value from the [`Capybara.default_selector`][] configuration:
+
+```ruby
+page.html # => '<div id="greeting">Hello world</div>'
+
+Capybara.default_selector = :css
+
+page.find('div').text     # => 'Hello world'
+
+Capybara.default_selector = :xpath
+
+page.find('.//div').text # => 'Hello world'
+```
+
+The locator argument's semantics are context-specific, and depend on the
+selector. The types of arguments are varied. Some selectors support `String` or
+`Regexp` arguments, while others like `:table_row` support `Array<String>` and
+`Hash<String, String>`:
+
+```ruby
+page.html # => '<label for="greeting">Greeting</label>
+                <input id="greeting" name="content">'
+
+# find by the <input> element's [id] attribute
+page.find(:id, 'greeting') == page.find_by_id('greeting') # => true
+
+# find by the <input> element's [id] attribute
+page.find(:field, 'greeting') == page.find_field('greeting') # => true
+
+# find by the <input> element's [name] attribute
+page.find(:field, 'content') == page.find_field('content') # => true
+
+# find by the <label> element's text
+page.find(:field, 'Greeting') == page.find_field('Greeting') # => true
+
+page.html # => '<table>
+                  <tr>
+                    <th>A</th>
+                    <th>B</th>
+                  </tr>
+                  <tr>
+                    <td>1</td>
+                    <td>2</td>
+                  </tr>
+                </table>'
+
+# find by <td> content
+page.find(:table_row, ['1', '2']) == page.find(:css, 'tr:last-of-type') # => true
+
+# find by <th> content paired with corresponding <td> content
+page.find(:table_row, 'A' => '1') == page.find(:table_row, 'B' => '2') # => true
+```
+
+### <a name="selectors-filters"></a> Filters
+
+All filters are optional. The supported set of keys is a mixture of both global
+and context-specific filters.The supported types of values depend on the
+context:
+
+```ruby
+page.html # => '<a href="/">Home</a>'
+
+# find by the [href] attribute
+page.find_link(href: '/') == page.find_link(text: 'Home') # => true
+
+page.html # => '<div id="element" data-attribute="value">Content</div>'
+
+# find by the [id] attribute
+page.find(id: 'element') == page.find(text: 'Content') # => true
+
+# find by the [data-attribute] attribute
+page.find(:element, 'data-attribute': /value/) == page.find(text: 'Content') # => true
+
+page.html # => '<input type="checkbox">'
+
+# find by the absence of the [checked] attribute
+page.find_field(checked: false) == page.find_field(unchecked: true) # => true
+```
+
+The predicate block is always optional. When there are results for a selector
+query, the block is called with each item in the result set. When the block
+evaluates to true, the item is included from the result set. Otherwise, the item
+is excluded:
+
+```ruby
+page.html # => '<input role="switch" type="checkbox" checked>'
+
+switch = page.find_field { |input| input["role"] == "switch" }
+field = page.find_field(checked: true)
+
+switch == field # => true
+```
+
+[`find`]: https://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders:find
+[`all`]: https://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders:all
+[`Capybara.default_selector`]: https://rubydoc.info/github/teamcapybara/capybara/master/Capybara%2Econfigure
+[`find_by_id`]: https://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders:find_by_id
+[`find_field`]: https://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders:find_field
+[`find_link`]: https://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders:find_link
+
 ## <a name="matching"></a>Matching
 
 It is possible to customize how Capybara finds elements. At your disposal
@@ -799,7 +925,7 @@ expect(page).to have_content('baz')
 If clicking on the *foo* link triggers an asynchronous process, such as
 an Ajax request, which, when complete will add the *bar* link to the page,
 clicking on the *bar* link would be expected to fail, since that link doesn't
-exist yet. However Capybara is smart enough to retry finding the link for a
+exist yet. However, Capybara is smart enough to retry finding the link for a
 brief period of time before giving up and throwing an error. The same is true of
 the next line, which looks for the content *baz* on the page; it will retry
 looking for that content for a brief time. You can adjust how long this period
@@ -813,13 +939,25 @@ Be aware that because of this behaviour, the following two statements are **not*
 equivalent, and you should **always** use the latter!
 
 ```ruby
-!page.has_xpath?('a')
-page.has_no_xpath?('a')
+# Given use of a driver where the page is loaded when visit returns
+# and that Capybara.predicates_wait is `true`
+# consider a page where the `a` tag is removed through AJAX after 1s
+visit(some_path)
+!page.has_xpath?('a')  # is false
+page.has_no_xpath?('a')  # is true
 ```
 
-The former would immediately fail because the content has not yet been removed.
-Only the latter would wait for the asynchronous process to remove the content
-from the page.
+First expression:
+- `has_xpath?('a')` is called right after `visit` returns. It is `true` because the link has not yet been removed
+- Capybara does not wait upon successful predicates/assertions, therefore **has_xpath? returns `true` immediately**
+- The expression returns `false` (because it is negated with the leading `!`)
+
+Second expression:
+- `has_no_xpath?('a')` is called right after `visit` returns. It is `false` because the link has not yet been removed.
+- Capybara waits upon failed predicates/assertions, therefore **has_no_xpath? does not return `false` immediately**
+- Capybara will periodically re-check the predicate/assertion up to the `default_max_wait_time` defined
+- after 1s, the predicate becomes `true` (because the link has been removed)
+- The expression returns `true`
 
 Capybara's RSpec matchers, however, are smart enough to handle either form.
 The two following statements are functionally equivalent:
@@ -954,12 +1092,17 @@ Capybara.default_selector = :xpath
 find('.//ul/li').text
 ```
 
-Capybara allows you to add custom selectors, which can be very useful if you
-find yourself using the same kinds of selectors very often:
+Capybara provides a number of other built-in selector types. The full list, along
+with applicable filters, can be seen at [built-in selectors](https://www.rubydoc.info/github/teamcapybara/capybara/Capybara/Selector)
+
+Capybara also allows you to add custom selectors, which can be very useful if you
+find yourself using the same kinds of selectors very often. The examples below are very
+simple, and there are many available features not demonstrated. For more in-depth examples
+please see Capybaras built-in selector definitions.
 
 ```ruby
-Capybara.add_selector(:id) do
-  xpath { |id| XPath.descendant[XPath.attr(:id) == id.to_s] }
+Capybara.add_selector(:my_attribute) do
+  xpath { |id| XPath.descendant[XPath.attr(:my_attribute) == id.to_s] }
 end
 
 Capybara.add_selector(:row) do
@@ -976,9 +1119,9 @@ an XPath expression generated through the XPath gem. You can now use these
 selectors like this:
 
 ```ruby
-find(:id, 'post_123')
-find(:row, 3)
-find(:flash_type, :notice)
+find(:my_attribute, 'post_123') # find element with matching attribute
+find(:row, 3) # find 3rd row in table body
+find(:flash_type, :notice) # find element with id of 'flash' and class of 'notice'
 ```
 
 ## <a name="beware-the-xpath--trap"></a>Beware the XPath // trap
@@ -1070,6 +1213,13 @@ additional info about how the underlying driver can be configured.
   are testing for specific server errors and using multiple sessions make sure to test for the
   errors using the initial session (usually :default)
 
+* If WebMock is enabled, you may encounter a "Too many open files"
+  error. A simple `page.find` call may cause thousands of HTTP requests
+  until the timeout occurs. By default, WebMock will cause each of these
+  requests to spawn a new connection. To work around this problem, you
+  may need to [enable WebMock's `net_http_connect_on_start: true`
+  parameter](https://github.com/bblimke/webmock/blob/master/README.md#connecting-on-nethttpstart).
+
 ## <a name="threadsafe"></a>"Threadsafe" mode
 
 In normal mode most of Capybara's configuration options are global settings which can cause issues

data/lib/capybara/config.rb

@@ -7,14 +7,13 @@ module Capybara
   class Config
     extend Forwardable
 
-    OPTIONS = %i[app reuse_server threadsafe default_wait_time server
-                 default_driver javascript_driver allow_gumbo].freeze
+    OPTIONS = %i[
+      app reuse_server threadsafe server default_driver javascript_driver use_html5_parsing allow_gumbo
+    ].freeze
 
-    attr_accessor :app
-    attr_reader :reuse_server, :threadsafe
-    attr_reader :session_options
+    attr_accessor :app, :use_html5_parsing
+    attr_reader :reuse_server, :threadsafe, :session_options # rubocop:disable Style/BisectedAttrAccessor
     attr_writer :default_driver, :javascript_driver
-    attr_accessor :allow_gumbo
 
     SessionConfig::OPTIONS.each do |method|
       def_delegators :session_options, method, "#{method}="
@@ -25,10 +24,12 @@ module Capybara
       @javascript_driver = nil
     end
 
-    attr_writer :reuse_server
+    attr_writer :reuse_server # rubocop:disable Style/BisectedAttrAccessor
 
     def threadsafe=(bool)
-      raise 'Threadsafe setting cannot be changed once a session is created' if (bool != threadsafe) && Session.instance_created?
+      if (bool != threadsafe) && Session.instance_created?
+        raise 'Threadsafe setting cannot be changed once a session is created'
+      end
 
       @threadsafe = bool
     end
@@ -60,7 +61,7 @@ module Capybara
       @server = if name.respond_to? :call
         name
       elsif options
-        proc { |app, port, host| Capybara.servers[name.to_sym].call(app, port, host, options) }
+        proc { |app, port, host| Capybara.servers[name.to_sym].call(app, port, host, **options) }
       else
         Capybara.servers[name.to_sym]
       end
@@ -82,10 +83,22 @@ module Capybara
       @javascript_driver || :selenium
     end
 
-    def deprecate(method, alternate_method, once = false)
+    def deprecate(method, alternate_method, once: false)
       @deprecation_notified ||= {}
-      warn "DEPRECATED: ##{method} is deprecated, please use ##{alternate_method} instead" unless once && @deprecation_notified[method]
+      unless once && @deprecation_notified[method]
+        Capybara::Helpers.warn "DEPRECATED: ##{method} is deprecated, please use ##{alternate_method} instead: #{Capybara::Helpers.filter_backtrace(caller)}"
+      end
       @deprecation_notified[method] = true
     end
+
+    def allow_gumbo=(val)
+      deprecate('allow_gumbo=', 'use_html5_parsing=')
+      self.use_html5_parsing = val
+    end
+
+    def allow_gumbo
+      deprecate('allow_gumbo', 'use_html5_parsing')
+      use_html5_parsing
+    end
   end
 end

data/lib/capybara/cucumber.rb

@@ -22,6 +22,6 @@ end
 Before do |scenario|
   scenario.source_tag_names.each do |tag|
     driver_name = tag.sub(/^@/, '').to_sym
-    Capybara.current_driver = driver_name if Capybara.drivers.key?(driver_name)
+    Capybara.current_driver = driver_name if Capybara.drivers[driver_name]
   end
 end

data/lib/capybara/driver/base.rb

@@ -59,6 +59,14 @@ class Capybara::Driver::Base
     raise Capybara::NotSupportedByDriverError, 'Capybara::Driver::Base#status_code'
   end
 
+  def send_keys(*)
+    raise Capybara::NotSupportedByDriverError, 'Capybara::Driver::Base#send_keys'
+  end
+
+  def active_element
+    raise Capybara::NotSupportedByDriverError, 'Capybara::Driver::Base#active_element'
+  end
+
   ##
   #
   # @param frame [Capybara::Node::Element, :parent, :top]  The iframe element to switch to