Skip to content

ref(page): handle :pending_connection_errors in Cuprite instead of passing it to Ferrum - #355

Merged
route merged 1 commit into
mainfrom
feat/pending-connection-errors
Oct 30, 2026
Merged

route merged 1 commit into
mainfrom
feat/pending-connection-errors

Conversation

@route

@route route commented Oct 30, 2026

Copy link
Copy Markdown
Member

Ferrum deprecates the :pending_connection_errors browser option and PendingConnectionsError in rubycdp/ferrum#689. Cuprite now owns the option, the same way it does :js_errors since #354.

  • Cuprite keeps :pending_connection_errors (still true by default) out of Ferrum's options. With the option unset, Ferrum's go_to returns nil on a timeout in every version, so Cuprite raises its own error when that happens.
  • visit raises Capybara::Cuprite::PendingConnectionsError, with the same message and pendings as before. While Ferrum still has Ferrum::PendingConnectionsError, Cuprite's class inherits from it, so existing rescue Ferrum::PendingConnectionsError keeps working and prints a deprecation warning pointing at the rescue. Once Ferrum removes the class, Cuprite's inherits from Ferrum::StatusError.

Works with the released Ferrum 0.20.1 and with Ferrum main, so it doesn't need to wait for a Ferrum release or pin Ferrum.

…ssing it to Ferrum

Ferrum deprecates the browser option and PendingConnectionsError, so Cuprite keeps the option out of Ferrum's options
and raises its own PendingConnectionsError when go_to returns nil on a timeout. It inherits from Ferrum's while that
exists, so rescuing it keeps working with a warning, and from Ferrum::StatusError once it's removed.
@route
route merged commit fae986c into main Oct 30, 2026
6 checks passed
@route
route deleted the feat/pending-connection-errors branch October 30, 2026 15:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant