Change not triggered

[tjtuom]

I have a jQuery change event registered with $('#tags fieldset:last li:first input').live('change', ...). When I fill the field with fill_in the change event does not get triggered. I have to manually trigger it with page.find('#event_tags_attributes_0_name').trigger('change') in my test.

[senny]

any progress on this issue? I think i got the same problem with the jQuery autocompleter. The event is never fired when I use fill_in to enter content into the field.

[h-lame]

change is not the only event not triggered. For this bug to be fixed we'd need to trigger focus, blur, change and possibly click, keyup, keydown and keypress as well (depending on the element in question). It depends, I suppose, what fill_in is supposed to simulate, a user interacting with the form, or JS interacting with the form, as I'm not sure any events get triggered when you use JS to change the value of a form element (not sure about this - might be browser specific).

Maybe we need a set of high level methods that simulate typical browser events when elements are interacted with, and then we can change our code that uses fill_in to use those instead?

[tjtuom]

I think there should be, like you said, some high level methods that simulate a user interacting with a form that trigger events that fit the 80% case. There should also be a lower level api for more granular control for those that are in the 20%.

For instance I don't think fill_in should normally trigger click events because the user can navigate via the keyboard but focus, blur, change and key press/down/up events are something that I think should always be triggered since I can't think of a way for a user to enter text without triggering them in the browser.

[smparkes]

So, is there any consensus on this?

Things like focus and blur are themselves going to be tough. I'm not sure about change: I don't use it that much and don't know the semantics. Should every fill_in send change? Is that going to help the use with autocompleter?

This stuff is going to be tricky to implement outside a real browser. The closer you get to UI stuff, the less env.js looks like a browser.

[bcardarella]

I don't see why it shouldn't be in. I have several checkboxes, when a change event is detected on the checkbox something happens. Why wouldn't capybara-envjs support this?

[smparkes]

Change on a checkbox should be relatively easy. Just a lack of time.

It's things related to I/O devices (mouse, keyboard) or that are layout-dependent that are difficult.

[bcardarella]

Is this a envjs thing or a capybara-envjs thing? If it is your code can you point out where I can take a look to see if I can hack on it?

[smparkes]

It's an env-js thing.

The code is in src/window/event.js. That code is rather old and crufty. I've made patches to it to accommodate some low hanging fruit that I and others have needed, but something like live events requires a thorough look at all the bubbling code, which I haven't had time to do.

The main java code may have cleaned some or all of this up, but the merge back to main is a significant project which we'd all like but no one seems to have been able to make time for.