user-event: Regression: Click event suddenly stopped working (Reactstrap / Popper.js 1.x)

If somebody still has this problem skipPointerEventsCheck option was introduced and can be used in the following way:

userEvent.click(await screen.findByText('Zoom'), {}, { skipPointerEventsCheck: true });

Cool! I’ll try get something up next week 😃

Workaround for version 14.0.0+:

import { screen, waitFor } from '@testing-library/react';
import userEvent, { PointerEventsCheckLevel } from '@testing-library/user-event';

test('workaround for pointer-events caching', async () => {
  // keep helpful pointer-event checks enabled until
  // they start causing errors (e.g. with popper.js + react-bootstrap)
  const user = userEvent.setup();

  // click a button with label 'Open Menu'
  // that opens a menu div with transition
  await user.click(screen.getByText('Open Menu'));

  // wait for div[role=menu] to be interactive
  await waitFor(() => {
    // do a manual check that confirms the popup
    // actually removes its pointer-events style
    expect(
      window.getComputedStyle(screen.getByRole('menu')).pointerEvents
    ).not.toBe('none');
  });

  // create a sub-instance of userEvent, disabling pointerEventsCheck,
  // then click a menu item
  await user
    .setup({ pointerEventsCheck: PointerEventsCheckLevel.Never })
    .click(await screen.findByText('Menu Item'));
});

@ph-fritsche I’ve also experienced this issue, and even though I fully understand the rationale behind this decision (and think it makes sense to consider no-pointer-events as being non-clickable), I think we could perhaps improve this behaviour.

Similar to how testing-library has the getBy query which will error if the element is not found, and the convenient findBy ( / waitFor) helpers to retry until the element is found, could it make sense to add a behaviour which would throw an error if we try to click a non-clickable element? (i.e. disabled, or no pointer events). (or at a minimum, a console.warning when this occurs)

This would really ease the DX for people dealing with external libraries where you can’t easily control this behaviour, animated components, and as well make it way more clear why tests are failing. Right now, it’ll just ‘no-op’ if the element is not clickable, giving the responsibility of raising an error to the next assertion, and thus easily making the cause of the test failure quite obscure.

This would also make it way easier to work around when you have animating components or inflexible libraries: you’d then simply have to wrap your click in

await waitFor(() => userEvents.click(screen.getByRole('button')))

Please let me know what you think and if this deserves its own ticket. I’d also be happy to try contribute this to the project if this is something you’d be interested in.

pointer-events is auto.

@vicrep Don’t get me wrong. If you feel strongly about this, a feature request in a separate issue is welcome. It’s just that at the moment I fear it brings a couple of new problems while not really solving one. If you come up with a consistent policy for such a flag that we could implement across our APIs and it receives positive feedback, I would consider an implementation.

@ph-fritsche I was thinking, could we consider adding a force option to user events, which bypasses interactivity checks? That way people can still use library for user events instead of falling back to the inferior fireEvent.* , or inconsistently using one or the other. (Again, happy to contribute)

Something like

userEvent.click(element, null, { force: true })

It’s nice to have errors if elements can’t be clicked. But I can’t solve the initial issue.

My issue was solved by waiting for popper to rerender with the correct styles

I tried a number of different ways to do this:

• doing a simple timeout, ranging from 0 to 1000ms
• overwriting pointer-events with auto at the point where I think it must be

•   await waitFor(() =>
      expect(
        hasPointerEvents(container.querySelector('bp3-transition-container')),
      ).toBe(true),
    );
  

•       await waitFor(() =>
      expect(
        userEvent.click(screen.getByLabelText('Tue Dec 10, 2019')),
      ).not.toThrow(),
    );
  

As of now I sadly can’t upgrade the project away from popper v1, which is used by blueprint.

In the final application the pointer events are set to auto as expected.

I’m pretty much stuck here, the only way I know which “solves” this is by using fireEvent.click instead

@markivancho how did you solve this?

I am facing the same issue with v13.1.x. I am using react-popper v1.3.6

We’ve added support for pointer-events in v13.1.0.

Could you check the computed pointer-events value for the element that you’re trying to click? Per window.getComputedStyle(element)['pointer-events'] and through developer console of your browser.

It returns auto in the browser’s developer console but returns none when I log it in the test file.

As mentioned by @markivancho , react-popper adds pointer-events: none as initial style to the popper element. Then the element re-renders and updates the value to auto. This creates a race-condition as when the click event is triggered, the value of pointer-events is still none

Adding a waiting time of “0 ms” resolves this issue. await new Promise(res => setTimeout(() => res(), 0))

But, it’s not feasible to add this workaround for multiple failing tests.