-
-
Notifications
You must be signed in to change notification settings - Fork 94
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
Comments
@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. |
@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 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 |
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. |
The I also tried removing the explicit Another thing I've been wondering about: when you click this particular button, the server responds with javascript, eg 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 |
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 ( |
Describe the bug
Working on switching from Selenium to cuprite. One of the errors I see frequently is
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 doingrender 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):
Additional context
N/A
The text was updated successfully, but these errors were encountered: