The keydown.Tab behaviour handler assumes that the event target will always be the origin for determining focus

[andrewhayward]

Reproduction example

https://codesandbox.io/p/devbox/lgshc5

Prerequisites

1. Add an onKeyDown handler to a focusable node
2. Inside the handler, change the focused node to something else
3. Include a simulated tab keypress in a test (using user.tab() or a lower level method)

Expected behavior

The Tab keydown behaviour handler should use the currently focused element as the source for determining the tab destination.

Actual behavior

The Tab keydown behaviour handler uses the event target as the source for determining the tab destination.

User-event version

14.5.2

Environment

No response

Additional context

This is niche behaviour, but is used to create focus traps, etc, to constrain tabbing. This may well be causing #820.

[andrewhayward]

Having done a bit more digging, it seems like the entire dispatch/behaviour lifecycle is open to the same fragility. It's highly unlikely that the active element is going to change in most cases, but by constructing the behaviorImplementation callback before dispatching the event, there's no guarantee that the context won't have changed by the time its called.

I may well be missing something obvious, but would it be worth not passing the target initially, and instead passing it as an argument to the behaviour callback?

const behaviorImplementation = preventDefault
  ? () => {}
  : (behavior[type] as BehaviorPlugin<EventType> | undefined)?.(
      event,
      this,
    )

...

behaviourImplementation(currentTarget);

The original target would still be available through event, if it was needed.

[GorenDaniel]

It reproduces with the focus-trap component of Material-UI, can be used for testing.
https://mui.com/base-ui/react-focus-trap/