Closed ball-hayden closed 6 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 😦
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
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>
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" . .
@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 ?
Fixed in master
Steps to reproduce:
1) Install Capybara webkit at 90d3196 2) Have a page including the following
3) Have the following test:
4) Capybara webkit raises a
Capybara::Webkit::InvalidResponseError