Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KeyboardEvents not firing of handlers #122

Closed
WhoAteDaCake opened this issue Jun 21, 2018 · 18 comments
Closed

KeyboardEvents not firing of handlers #122

WhoAteDaCake opened this issue Jun 21, 2018 · 18 comments

Comments

@WhoAteDaCake
Copy link

  • react-testing-library version: 4.0.1
  • react version: 16.4.1
  • node version: 8.9.4
  • npm (or yarn) version: (yarn 1.7.0)

Relevant code or config:

    const { container, debug } = render(<input onKeyDown={console.log} />);
    fireEvent(
      container.getElementsByTagName('input')[0],
      new KeyboardEvent('keyDown', { key: 'Enter', keyCode: 13, which: 13 })
    );

What you did:

I am trying to simulate keyboard events to validate my input component. To do that I tried to use fireEvent function with keydown and keyDown types but neither worked.

What happened:

Event handlers are not getting called

Reproduction:

https://codesandbox.io/s/n32nmp18rl

Problem description:

I can't simulate any input via keyboard

Suggested solution:

When i tried to simulate events using reacts ref and react-dom/test-utils Simulate class it seemed to work.

@kentcdodds
Copy link
Member

It's because you need to set the bubbles property to true so react's event delegation will work. Like so: https://codesandbox.io/s/rm4lqyn9mp

This is why I recommend you use fireEvent.keyDown instead which has defaults like this, like so: https://codesandbox.io/s/myyxkrn52j

Good luck.

@mukeshsoni
Copy link

The onChange callback on <input type='checkbox' /> is not called on simulating a spacebar event. The onChange is actually called if i press space when the checkbox is in focus.

https://codesandbox.io/s/6jzvyz5y1z

@kentcdodds
Copy link
Member

See the README. For checkboxes you should fire the click event, not the change event.

@mukeshsoni
Copy link

But i am not firing the change event. I want to test keyboard interactions. In this case, i want to test the spacebar keydown.

@kentcdodds
Copy link
Member

Ah, I see what you mean. You want this: testing-library/dom-testing-library#107

@mukeshsoni
Copy link

Don't know if i followed the thread correctly. Does it mean that to make the checkbox change state based on keyboard spacebar press, i need to fire a combination of events?

What is the best way to test accessibility related keyboard scenarios? E.g. tab to focus an element and then press space or enter to perform action on the element.

@kentcdodds
Copy link
Member

I'm honestly not sure. For your specific example, I think you should be able to rely on the way that browsers deal with checkboxes and use click. Don't bother testing the browser itself. Just trust that it does the right thing when a user hits the space-key when the checkbox has focus.

@mukeshsoni
Copy link

Hmm. I was trying to add these tests because we ran into a situation where a coworker of mine wrote a component and thought it was accessible but didn't test it for keyboard interactions manually. I caught it in code review but was wondering if we could make keyboard interaction tests a norm.

Will try to add those tests at selenium level for now. Thanks for your time!

@kentcdodds
Copy link
Member

Hmmm... Are you sure it was a checkbox? How did they make a checkbox that didn't work with the space bar?

@mukeshsoni
Copy link

mukeshsoni commented Sep 21, 2018

It was a switch which had a checkbox underneath so that we could use the checkbox onChange and focus browser functionality. The switch was implemented by styling the accompanying label but the <input> was hidden which made it non-focusable (is that a word?).

@kentcdodds
Copy link
Member

Ah, I see, so you don't want to test the keyup on the input, you want to test it on the switch...

@mukeshsoni
Copy link

Yes, that's correct. I tried all combinations - on the input, the switch container, document and document.body. No luck.

@kentcdodds
Copy link
Member

So when the user's actually using the component, where are they focused when they hit the space bar?

@mukeshsoni
Copy link

I removed the display: none from <input> and instead made it position: aboslute; opacity: 0.

Now i can hit 'Tab' and the focus moves to the switch. On pressing space bar, the switch toggles between on/off, just like a checkbox.

@kentcdodds
Copy link
Member

You may consider doing the CSS like bootstrap's sr-only-focusable: https://getbootstrap.com/docs/3.3/css/#helper-classes-screen-readers

I know that some screen readers will skip elements that aren't visible unless it's done in a certain way.

@kentcdodds
Copy link
Member

Here's the CSS for sr-only:

    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0,0,0,0);
    border: 0;

I can't find the css for sr-only-focusable.

@smacpherson64
Copy link

smacpherson64 commented Sep 21, 2018

@kentcdodds HTML5Boilerplate has a focused one:

https://github.com/h5bp/html5-boilerplate/blob/master/src/css/main.css#L148-L157

@mukeshsoni
Copy link

Thanks!
I wrote something very similar

position: absolute;
width: 1px;
height: 1px;
border: 0;
clip: rect(0, 0, 0, 0);
opacity; 0;

Had no idea there was so much css involved to have an element hidden behind another one but still be present in the DOM :)

julienw pushed a commit to julienw/react-testing-library that referenced this issue Dec 20, 2018
Closes testing-library#122 

**What**:

`getByText` section in the readme.

**Why**:

The current example is not accurate.

**How**:

Since the `exact` option is true by default, I use a regular exception with ignore case to find the desired element by text.

**Checklist**:

- [X] Documentation
- [ ] Tests N/A
- [X] Ready to be merged
- [X] Added myself to contributors table
lucbpz pushed a commit to lucbpz/react-testing-library that referenced this issue Jul 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants