Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

click_on times out in some circumstances #270

Open
sdhull opened this issue Jul 3, 2024 · 5 comments
Open

click_on times out in some circumstances #270

sdhull opened this issue Jul 3, 2024 · 5 comments

Comments

@sdhull
Copy link

sdhull commented Jul 3, 2024

Describe the bug
Working on switching from Selenium to cuprite. One of the errors I see frequently is

Ferrum::TimeoutError:
       Timed out waiting for response

Digging in to one example, I've found the offending line is click_link("Some text") and the link in question is sending an ajax request to the server and the endpoint is doing render js: "..."

Examining the test server log, it shows the request does get received by the server & response is rendered in 95ms

To Reproduce
Sadly I don't have a way to repro, I'm still investigating.

Expected behavior
It seems like cuprite is trying to be too helpful here, trying to make sure "something happened" after clicking a link.

But IMO clicking a link should simply click the link and move on. If I want to wait for the next page to load I can do so with expect(page).to have_current_path(...) or if I want to wait for network requests to complete, or page to reload, that's all possible too.

Screenshots
N/A

Desktop (please complete the following information):

  • OS: macOS
  • Browser Chrome Version 124.0.6367.202 (Official Build) (arm64)
  • Version 0.15.1

Additional context
N/A

@pond
Copy link

pond commented Jul 4, 2024

@sdhull Please trying locking Cuprite to 0.15.0 and Ferrum to 0.14.0 in your Gemfile:

  gem 'ferrum',  '= 0.14.0'
  gem 'cuprite', '= 0.15.0'

...as it's possible you're seeing another manifestation of what we saw and reported as rubycdp/ferrum#470, BUT your symptoms are a little different. You're getting a timeout you don't expect, but it's handled properly.

If you downgrade those gems as described and your tests then reliably pass, please add a link to this issue under that Ferrum bug report so that we can start trying to collate possibly related evidence. If downgrading the gems doesn't help, well, so be it - whatever issue you are having is obviously something else.

@sdhull
Copy link
Author

sdhull commented Jul 8, 2024

@pond thanks for the response. Unfortunately pinning the versions did not help. And for my issue, it's pretty easily reproducible. One thing I'm wondering about is we register the driver like this, explicitly setting timeout:

Capybara.register_driver(:cuprite) do |app|
  Capybara::Cuprite::Driver.new(
    app,
    browser_options: { 'no-sandbox': nil, 'disable-smooth-scrolling': true },
    window_size: [1200, 800],
    # Increase Chrome startup wait time (required for stable CI builds)
    process_timeout: 10,
    # Ferrum doesn't use the Capybara default_wait_time
    timeout: Capybara.default_max_wait_time,
    # Enable debugging capabilities with page.driver.debug(binding)
    inspector: ENV["INSPECTOR"],
    # Allow running Chrome in a headful mode
    headless: !ENV["CUPRITE_HEADLESS"].in?(%w[n 0 no false]),
    flatten: false
  )
end

Should we not be setting timeout for some reason?

@pond
Copy link

pond commented Jul 8, 2024

The issue on Ferrum (on my phone and don't have the link handy sorry, will post later) suggests adding option "flatten: false". If that doesn't fix it then you have another problem (which seems likely if version pinning made no difference).

A ten second process timeout is quite short - we have ours on 60! - and perhaps just remove the other timeout and let it rely on "someone's" defaults to see if things improve, rather than specifying the constant from Capybara.

@sdhull
Copy link
Author

sdhull commented Jul 8, 2024

The process_timeout is set to 10, but I had the timeout value set to 60 seconds locally (it's lower on CI).

I also tried removing the explicit timeout in the driver setup but alas, still no luck.

Another thing I've been wondering about: when you click this particular button, the server responds with javascript, eg Content-Type: text/javascript; charset=utf-8 with a javascript snippet as the response body. I wonder if this is messing up Ferrum somehow.

For now (just to try to make some progress on my branch) I'm just ignoring these exceptions by monkeypatching like so 😭

class Capybara::Node::Element
  alias_method :original_click, :click
  def click(*args, **kwargs)
    original_click(*args, **kwargs)
  rescue Ferrum::TimeoutError
    # ignoring these
  end
end

@pond
Copy link

pond commented Jul 9, 2024

Well the Ferrum issue - since I promised to link to it! - is rubycdp/ferrum#470 but it does not sound like the fault you have.

I'm not sure what is going on in that case, but having a button return a chunk of JavaScript sounds quite strange and is not what most of Cuprite's DSL is able to deal with, since that seems to be exclusively based around DOM operations on assumption of an HTML variant (although certainly it can handle other kinds of response). If you've tried it with Chrome non-headless so that you can see the steps being taken and verify that they seem correct (headless: true into Cuprite options) and still see a timeout, then it certainly looks like a CDP issue. That would most likely be a bug to submit to Ferrum, since that's where the timeout is arising.

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

No branches or pull requests

2 participants