Capybara::Node::Element#click not working about cuprite HOT 8 CLOSED

@vizcay could you please run your test with CUPRITE_DEBUG=true bundle exec rspec ... option turned on?

from cuprite.

@route sure! Wasn't able to upload here because it was more than 64k.. I've send it to your personal email.

from cuprite.

@vizcay most likely you have an alert which you didn't handle with accept_confirm or dismiss_confirm after clicking at a.btn.btn-mini.retencion_ganancias_calcular

{"url":"http://127.0.0.1:56656/empresas/6861/pagos/new","message":"Se ha producido un error en el servidor, cont\u00E1ctese con el soporte t\u00E9cnico.","type":"alert","hasBrowserHandler":false,"defaultPrompt":""}

from cuprite.

@route as a matter of fact, your are right. When I get the timeout is because there is an alert "blocking" the page. Now, since this doesn't happens with selenium (chromedriver o geckodriver both work fine on those tests) I did a little more research and reduced the problematic error to this:

    it 'alert date is out of range' do
      visit new_invoice_path(test_business)
      message = accept_alert do
        fill_in 'invoice_date', with: input_date(Date.current - 31)
        find('body').click # => HANGS HERE
      end
      expect(message).to eq 'Date is out of 30 days range.'
    end

Now the spec with cuprite hangs at the line find('body').click as described, because the alert is already present on the page. But, with selenium, to force the alert (that is fired in the callback of the blur event of the invoice_date input) I need to "force the lost of focus" by the means of find('body').click (or clicking other input, or whatever similar).

So, the question is,

• This is intendend behaviour? A #fill_in should automatically fire a blur DOM event after completing it's job? I don't think so, at least is not the same that a human does automatically.

• This behaviour happens for all inputs or only input[type=date]? This is because I see this error happens only on date inputs.. but I'm not sure if the test suite has this same condition for other type of inputs.

from cuprite.

I believe cuprite has the same behavior as poltergeist and I think it's correct. Filling in any given input not only should trigger blur after filling but also first of all focus an element as well as remove previous value, so it's a lot of additional work. I think it's complete and find('body').click is an extra in my opinion.

from cuprite.

That's true, phantomjs works the same way (but it is not checking the alert it's open that cuprite is doing right so the test passes). I will solve it by always using force_blur_focus:

  def force_blur_focus
    page.find('body').click unless ENV['CUPRITE']
  end

Regarding which behaviour is better I'm not sure but IMHO trying to be as compatible as possible with selenium is not a bad idea. I will close this issue as the latter findings show that the find(xxx).click functionality is working right.

from cuprite.

@vizcay poltergeist accepts all popups by default, cuprite doesn't and in chrome it results in stop the world behaviour that waits for action. I think instead of timeout error it would be nice to see an error about unhandled modal window. To stick with selenium or poltergeist is an open question if you have 5k tests that worked on poltergeist it will be easier to switch to cuprite if behaviour is similar, same thing vice versa it depends. Though the driver claimed to be close poltergeist :)

from cuprite.

My solution was to start using driven_by :selenium,

from cuprite.