Make acceptance helpers fire native events instead of jQuery ones.

[cibernox]

Following issue #12569

Goal: To fire events in relatively accurate and cross-browser way.

Simulate real events in pure javascript accurately is nearly impossible, but
this is a best effort. This fires 3 different kind of events:

• MouseEvents: click, dbclick, mousedown, mouseup, mouseenter, mouseleave, ...
• KeyEvents: keydown, keypress and keyup
• Events: Anything other than mouse or keyboard events falls in this generic kind of event.

This should probably cover 99% of use cases.

Caveats found:

I've only encountered 2 failing tests after this refactor, both related to the same problem:

triggerEvent('.input', 'keydown', { keyCode: 13 });
// ...
equal(event.keyCode, 13, 'options were passed');

It turns that keyCode is a reserved property that only works with keyboardEvents, so although the event has this property mixed, the wrapped jquery event does not copy that property if the original event is not a keyboard event.
Seems very reasonable and probably that test was a bad example.

[cibernox]

There is some funkiness going on with the focusin event in phantom and in any other browser the window doesn't has the focus.

Wut?

[rwjblue]

Wut?

Yep.

[cibernox]

[cibernox]

@rwjblue I managed to remove al reliance in jquery except this line: https://github.com/cibernox/ember.js/blob/make_acceptance_helpers_fire_native_evets/packages/ember-testing/lib/helpers.js#L108

I tried everything but it couldn't find a way of firing a focusin event if the browser doesn't has the focus. I think that is the browser itself the one that is swallowing any event whose type is focusin.
Any idea?

[cibernox]

I've rebased this. The only jquery event I wasn't able to replace was triggering focusin in firefox when the window is not focused. Everything I tried failed.

[stefanpenner]

The only jquery event I wasn't able to replace was triggering focusin in firefox when the window is not focused. Everything I tried failed.

We have had lots of issues with this event on FF...

[stefanpenner]

Do we want to treat this as a bugfix or a new feature?

[cibernox]

Not sure. I'd say bugfix because firing jquery events instead of real events is being "less real" than we should be.

That said, I fear that this can be backwards incompatible in some weird edge case I haven't predicted, but it's just me being pessimistic. I'd try and see if someone reports.

[stefanpenner]

That said, I fear that this can be backwards incompatible in some weird edge case I haven't predicted, but it's just me being pessimistic. I'd try and see if someone reports.

I like this PR alot, but I share this concern. Which made me think, what if it was treated as a feature instead. It is possible that [bugfix canary] is sufficient, but lets ask señor @rwjblue

[rwjblue]

I like the idea of it being in a feature flag (and therefore easier to back out if we have to), but I would like to land it and then subsequently enable the feature nearly immediately (to let folks bang on it for a full canary and beta cycle).

@cibernox - Do you mind feature flagging it?

[stefanpenner]

I like the idea of it being in a feature flag (and therefore easier to back out if we have to),

ya good point.

[cibernox]

Added a ember-test-helpers-fire-native-events feature flag pre-enabled to true.
PR/commit has been labeled as [FEATURE canary]

[stefanpenner]

@cibernox nice!

[cibernox]

Any idea why the TEST_SUITE=each-package-test tests fail?

[rwjblue]

Restarted them

[cibernox]

Seems to fail consistently, but the output doesn't give me any clue of why

[cibernox]

Build is green now, but don merge yet, I will implement some suggestion by @runspired in slack tonight/tomorrow

[cibernox]

Ready to merge if build turns out green again.