keyEvent does not seem to trigger events in tests using input helper

[markcellus]

Hello, thanks for creating this package!

Currently, using keyEvent(), particularly for ENTER or ESC keycodes (13 and 27 respectively), on an {{input}} element in a component while running a phantomJS test does not fire the event.

Take the following test:

test('test does not work', function(assert) {
  this.set('escPressed', () => {
    // never called
    console.log('keyup called!');
    assert.ok(true);
  });
  this.render(hbs`{{input escape-press=(action escPressed)}}`);
  let input = find('input');
  focus(input);
  keyEvent(input, 'keyup', 27); // esc
});

After doing a bit of research, it appears that when creating events using KeyboardEvents or KeyEvents in the fire-event.js, PhantomJS assigns all keyCode property on events to 0, for reasons I'm not too sure of. As a result, Ember is not able to correctly detect the pressed key because keyCode is being set to 0 by PhantomJS.

A workaround was to create an event in a legacy way. For instance, instead of using keyEvent, triggering an event like this works.

   let evt = document.createEvent('CustomEvent');
   evt.initEvent('keyup', true, false);
   evt.keyCode = 27;
   input.dispatchEvent(evt);

This may be something that phantomjs may be able to fix in its package, but I was thinking it wouldn't be unreasonable for this package to support this?

[cibernox]

I'm a bit reluctant to add fixes for specific phantomjs bugs now that the project is officially defunct (the maintainer abandoned).

@rwjblue What do you think? I'd rather consider phantom unsupported.

[markcellus]

Ugh, you're right @cibernox. Wow the PhantomJS abandonment is new to me, although I saw it coming... After digging through PhantomJS's repo, I did come across an open issue that hints to the keyCode=0 deal which may be related

[rwjblue]

@cibernox - Ya, agreed. I think phantom edge cases can be unsupported. We should just be reasonable about patches for them (e.g. if its a small change without adding tech debt it may be fine)...

[markcellus]

FWIW, I was using 0.4.1 when seeing this issue. When downgrading back to 0.3.9, the issue went away.

[cibernox]

I believe that some work was done to better mimic browser behaviour: https://github.com/cibernox/ember-native-dom-helpers/commit/3d741374746917970d36fb1559fbabe325f03696

@RuslanZavacky Do you recall what was the change?

[RuslanZavacky]

@cibernox I have some concerns about using KeyboardEvent, to be honest. Going back to like 'legacy' events kinda fixes most of the issues. But I am not exactly sure, which is the right path :) Maybe because KeyboardEvents are so different and have like 3 different ways how to use them (+ browser differences)

[brandynbennett]

I'm having the same issue using version 0.5.0

[cibernox]

@brandynbennett If it's possible, I'd recomend trying headless chrome instead of phantom. Faster, more reliable. We haven't decided yet if this is something we want to fix.

[brandynbennett]

@cibernox That worked great for me locally :) Unfortunately my CI environment doesn't have Chrome installed. I'd install it myself, but we have a dedicated team for deployments and it's a longer process to change our box setup :/ I asked the team if they could add it, but it'll probably be a while before they finish it. I'm ok to work around it for now though. Headless Chrome definitely seems like the way to go.

[markcellus]

FWIW, we've since ditched PhantomJS in favor of Headless Chrome as you all have suggested here and works perfectly. I guess I understand the reservations of spending extra effort to support PhantomJS since it is unmaintained and very likely to be dead soon.

[GCheung55]

I'm experiencing a similar bug with the input helper on [email protected] and [email protected].

Here's my basic setup for the component: https://ember-twiddle.com/458c15dec9d3027cb92ee38c8e176e1a

I'm trying to simulate a form submission when the enter key is pressed on the input.

keyEvent does not work with {{input}} but did work with <input>.

[GCheung55]

Dug a little more and eventually came across Ember.TextField documentation that the {{input bubbles=true}} would bubble up the keyUp event to parent nodes.

Instead of using keyUp, I used keyPress instead. With keyPress, I do not have to set the bubbles property.

[GCheung55]

I'm also seeing an issue with PhantomJS and [email protected]. I think moving away from PhantomJS is ideal but I'll need to downgrade to [email protected] until my team can get Chrome installed in our CI servers.

[nlfurniss]

This is what we've been using to get around the issue until we move to headless Chrome

https://gist.github.com/nlfurniss/b6b8b69cdd9cb325d9339dfb5c8a6d92