Not behaving like the default javascript_driver #289

Closed
cj opened this Issue Mar 7, 2012 · 15 comments

Comments

Projects
None yet
5 participants

cj commented Mar 7, 2012

So I have:

          within '#claims_info' do
            select 'Test Carrier', from: 'Adverse Carrier'
            fill_in 'Claim Number', with: 'TEST123'
            fill_in 'Estimate Written Date', with: '10/20/2012'
            # Make sure the datepicker dropdown shows
            find(:xpath, '//body').find('.datepicker.dropdown-menu').should be_visible
            select 'Repair Shop', from: 'Appraisal Author'
            fill_in 'Deductible', with: '1000'
            select 'Collision', from: 'Type of Loss'
            fill_in 'Point of Impact', with: 'Rear'
          end

With the default Capybara.javascript_driver everything passes (launching the actual browser). But when using Capybara.javascript_driver = :webkit I get:

- Should fill in the new claims form
  expected no Exception, got #<RSpec::Expectations::ExpectationNotMetError: expected visible? to return true, got false>

cj commented Mar 7, 2012

[1331140135901][INFO]:    ChromeDriver 18.0.995.0
[1331140136117][FINE]:    Initializing session with capabilities {
   "browserName": "chrome",
   "chrome.detach": true,
   "chromeOptions": {
      "detach": true
   },
   "cssSelectorsEnabled": true,
   "javascriptEnabled": true,
   "nativeEvents": false,
   "platform": "ANY",
   "rotatable": false,
   "takesScreenshot": false,
   "version": ""
}

cj commented Mar 8, 2012

I came up with this work around for now https://gist.github.com/2003631 because the bug seems to do with it being headless and knowing how to deal with mouse/click events properly.

Owner

jferris commented Mar 9, 2012

Are you saying that Selenium triggers click events when you're filling in fields?

cj commented Mar 9, 2012

@jferris It's handling it differently (the correct way). I've spoken to a few people on IRC and they have the same issue. I got the idea above from @ogredude's work around (https://gist.github.com/2003109). It only has to do with when things are bound to a text input for instance http://www.eyecon.ro/bootstrap-datepicker/ or https://github.com/RobinHerbots/jquery.inputmask . The reason @ogredude made that work around in the above gist is because webkit was having issues with his autocomplete. Running in chrome or ff, non headless when the browser loads all the tests work just fine.

Owner

jferris commented Mar 9, 2012

@cj I believe you, I'm just trying to figure out what the actual difference is. Do you have any idea what events that plugin is listening to that capybara-webkit doesn't fire? Is it possible the events aren't being fired in the same order?

Which events are triggered when somebody fills in a field is kind of a tricky question, because there are actually several ways a user could do that through the interface. They could tab through, click through, type things out or paste things. In general, we try to fire events in the same way that Selenium does just because it's what people expect, but we're already passing all the capybara specs and it's not always clear how we differ from Selenium.

cj commented Mar 9, 2012

@jferris I'll get a repo setup with the different examples that don't work with webkit, I think it will make things a lot easier for you. I'll paste the link to it in here once I have it up :)

Owner

jferris commented Mar 9, 2012

@cj thanks a bunch

cj commented Mar 18, 2012

@jferris sorry for the delay, here's the repo https://github.com/cj/capybara-webkit-bug as you'll see, selenium passess and webkit fails.

cj commented Apr 17, 2012

@jferris have you had a chance to take a look at this yet?

Owner

jferris commented Apr 17, 2012

I haven't yet, sorry. I'll let you know as soon as I do.

Owner

jferris commented Jul 11, 2012

@cj thanks for putting that example together.

I finally got a chance to look at this today. I behaves differently on the current master than it originally did when you filed this issue, but the datepicker still isn't working quite right. I managed to fix a separate bug related to focus based on your test case, but it didn't actually fix your specific problem.

Currently, the datepicker ends up with the value __/0_/____, so I think there must be something weird going on with timing and how the datepicker things the user is entering the value. I'll spend more time on this again whenever I can.

Collaborator

mhoran commented Apr 2, 2013

@cj, could you try out the latest master? We've changed the code for setting values to send native events, just as Selenium does.

Hello I had the same problem and fix with a custom helper:

  def fill_mask(locator, options = {})
    raise "Must pass a hash containing 'with'" if not options.is_a?(Hash) or not options.has_key?(:with)
    field = find_field(locator)

    options[:with].split("").reverse.each do |char|
      fill_in locator, :with => char
    end

    field.trigger('blur')
  end

I noticed that the field needs filling with character at a time, the end of the text to start

Can someone confirm whether this is still an issue in the latest version of capybara-webkit?

I'll close this issue due to inactivity. Please re-open it if you're still experiencing these issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment