Skip to content
This repository has been archived by the owner on Nov 27, 2020. It is now read-only.

Events fired on fill_in #43

Closed
mremolt opened this issue Apr 17, 2012 · 13 comments
Closed

Events fired on fill_in #43

mremolt opened this issue Apr 17, 2012 · 13 comments
Milestone

Comments

@mremolt
Copy link

mremolt commented Apr 17, 2012

I tried switching from capybara-webkit to poltergeist and stumbled over some differences, especially which events get fired.

When I execute fill_in on a textarea, CW fires:

  • focus
  • keydown/keyup for every letter inserted
  • change
  • blur

Poltergeist fires:

  • change

This doesn't really simulate real user interaction and resulted in some broken tests in my suite.

@jonleighton
Copy link
Contributor

Looks like capybara-webkit manually fires the events in JS.

We can do the same as a short-term solution, but in the longer term I'd like to submit a patch to PhantomJS to generate native keystrokes and let WebKit decide what events that should fire.

@atambo
Copy link

atambo commented Apr 19, 2012

+1 on this. Lots of autocomplete tests will probably need this.

@mremolt
Copy link
Author

mremolt commented Apr 19, 2012

I personally wouldn't even delegate that task to PhantomJS.

I see PJS as the Browser and Poltergeist (or any capybara driver) as the user at the keyboard.

As a user, you type every key yourself and then blur out of the field to the next one or press a button. You don't "tell" the browser "paste that text here" and the Browser initializes keystrokes.

But that's just my 5 cent.

@dnesteryuk
Copy link
Contributor

I had the same problem with using Poltergeist. But, might be I can fix it with Javascript and we can use it until Phantomjs fires these events by itself.

As far as I understood those things from Webkit driver must be brought to the Poltergeist? I want to try to contribute that.

@jonleighton
Copy link
Contributor

@nestd yes, we can fire events with js until such time as we can get a patch in phantomjs to emulate proper "typing". Here's the code that currently sets input values - so you need to change that to closer resemble the capybara-webkit version.

Thanks

@dnesteryuk
Copy link
Contributor

ok, I will do that

@jonleighton
Copy link
Contributor

This was fixed #54

@benhoskings
Copy link

This issue seems to have reappeared. I found that using #fill_in doesn't trigger autocomplete AJAX, but then connecting to the remote web inspector and firing a keydown() on the input field in question caused it to trigger.

I've worked around it with a little helper:

def fill_in field, options
  super
  page.execute_script "$('label:contains(#{field})').siblings('input').keydown()"
end

@earnold
Copy link

earnold commented Mar 20, 2013

I too have found the the same issue with fill_in

This does not trigger keydown events:

fill_in("q", with: "par")

While this does:

 page.execute_script '$("#q").val("par").keydown()'

The output from debug looks like this:

{"name"=>"find", "args"=>[".//*[self::input | self::textarea][not(./@type = 'submit' or ./@type = 'image' or ./@type = 'radio' or ./@type = 'checkbox' or ./@type = 'hidden' or ./@type = 'file')][(((./@id = 'q' or ./@name = 'q') or ./@placeholder = 'q') or ./@id = //label[contains(normalize-space(string(.)), 'q')]/@for)][not(./@disabled)] | .//label[contains(normalize-space(string(.)), 'q')]//.//*[self::input | self::textarea][not(./@type = 'submit' or ./@type = 'image' or ./@type = 'radio' or ./@type = 'checkbox' or ./@type = 'hidden' or ./@type = 'file')][not(./@disabled)]"]}
{"response"=>{"page_id"=>2, "ids"=>[0]}}
{"name"=>"tag_name", "args"=>[2, 0]}
{"response"=>"INPUT"}
{"name"=>"attribute", "args"=>[2, 0, "type"]}
{"response"=>"text"}
{"name"=>"set", "args"=>[2, 0, "par"]}
{"response"=>true}

@jaredbeck
Copy link

Thanks @benhoskings, the keydown() worked for my autocomplete.

@Valve
Copy link

Valve commented Dec 24, 2013

When erasing the content with:
fill_in 'input', with: ''
the key events are not raised. The problem is here, I think: https://github.com/jonleighton/poltergeist/pull/54/files#diff-893b71c0619c86f7b1058a9e9875af42R157

@jjb
Copy link

jjb commented Sep 24, 2015

I am also experiencing this problem.

@Bastes
Copy link

Bastes commented Aug 26, 2016

I'm also bumping into it ; sadly, this is a feature that would make sense to test what happens when emptying a search field for example.

(using poltergeist 1.10.0)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

10 participants