Skip to content
This repository

Not behaving like the default javascript_driver #289

Open
cj opened this Issue March 07, 2012 · 13 comments

4 participants

Joe Ferris Matthew Horan Gustavo Warmling Teixeira
cj commented March 07, 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 March 07, 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 March 08, 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.

Joe Ferris
Owner

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

cj commented March 09, 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.

Joe Ferris
Owner

@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 March 09, 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 :)

Joe Ferris
Owner

@cj thanks a bunch

cj commented March 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 April 17, 2012

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

Joe Ferris
Owner

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

Joe Ferris
Owner

@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.

Matthew Horan
Collaborator

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

Gustavo Warmling Teixeira

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.