search

thoughtbot / capybara-webkit

A Capybara driver for headless WebKit to test JavaScript web apps
https://thoughtbot.com/open-source
MIT License
1.97k stars 428 forks source link

Input with name="type" causes an InvalidReponseError #1010

Closed ball-hayden closed 6 years ago

ball-hayden commented 7 years ago

Steps to reproduce:

1) Install Capybara webkit at 90d3196 2) Have a page including the following

<form>
  <input name="type" />
</form>

3) Have the following test:

    visit my_page_path
    within "form" do
      expect(page).to have_content "can't be blank"
    end

4) Capybara webkit raises a Capybara::Webkit::InvalidResponseError

ball-hayden commented 7 years ago

My apologies - I've just seen the note about https://github.com/thoughtbot/capybara-webkit/wiki/Reporting-Crashes.

I'm also struggling to reproduce this in a minimal test case, so there may be something more complex going on here 😦

ball-hayden commented 7 years ago

Right. I've managed to reproduce it - I'll try and get a minimal example published somewhere next week.

For now, here's the debug log produced: https://gist.github.com/ball-hayden/d66d018b205206691245b27ebf321215

twalpole commented 7 years ago

This fails with the released 1.14.0 too. The following code will reproduce it and changing the input elements name to something other than "type" prevents the error as does changing the form to a div

require 'capybara/dsl'
require 'capybara/webkit'

html = DATA.read
app = proc { |env| [200, { "Content-Type" => "text/html" }, [html] ] }

sess = Capybara::Session.new(:webkit, app)
sess.visit('/')
form = sess.find('form')
puts form.text

__END__

<!doctype html>
<html>
<head>
<title>Some title</title>
</head>
<body>
  <form>
    <input name="type"/>
  </form>
</body>
</html>
twalpole commented 7 years ago

This is happening because form elements have accessors to their inputs by name - Therefore form.type refers to the input element if there is one named "type". This causes a problem in the text method when it checks the element for a type - https://github.com/thoughtbot/capybara-webkit/blob/master/src/capybara.js#L69 . It would also be an issue if an input element in the form had name "tagName" . .

twalpole commented 7 years ago

@mhoran @jferris Playing with this a bit, form elements create all sorts of issues if they contain fields with names that conflict with methods 'type', 'tagName', 'innerHTML', 'innerText', 'textContent', etc... - Fixing for "type" makes sense since that seems like a common enough field name, however how much effort do you think it's worth trying to fix the others? Also in the text method - https://github.com/thoughtbot/capybara-webkit/blob/master/src/capybara.js#L69 - I'm unclear why it even checks for type since the only value it cares about is 'textarea' which would come from the tagName ?

twalpole commented 6 years ago

Fixed in master