mirror of
https://github.com/coder/coder.git
synced 2026-09-22 13:10:21 +08:00
fixes DEVEX-402 Alternative to #26077, which aimed to address this flake in UsersPage.stories.tsx only: >Unable to perform pointer interaction as the element has `pointer-events: none` In the original PR I was going to "fix" the flake by adding `pointerEventsCheck: Never` like we have in 2 other tests. However, resetting `pointer-events` during `beforeEach` in our global Vitest setup removes the need for that `pointerEventsCheck` workaround. 🙂 tl;dr: Each of these 3 tests were failing because of an immediately preceding test which opens a Radix Dialog, setting `pointer-events: none` on the body element. Co-written with Coder Agents. Relevant chat responses: >**The actual root cause is story isolation.** The previous story (`UpdateUserRoleSuccess`) opens a Radix Dialog, which triggers Radix's `DismissableLayer` to set `document.body.style.pointerEvents = "none"`. When that story completes, Storybook unmounts the React tree, but the cleanup of `body.style.pointerEvents` is tied to a `useEffect` cleanup in `DismissableLayer`. If Storybook begins the next story's play function before the browser has fully flushed the previous unmount cycle, `document.body.style.pointerEvents` is still `"none"`. The "Open menu" button, which is a plain table button with no Radix modal layer above it providing `pointer-events: auto`, inherits `"none"` from body, and the first click fails. > >**Why it's flaky:** The Storybook Vitest plugin (`@storybook/addon-vitest`) runs stories sequentially in the same browser page. When `UpdateUserRoleSuccess` finishes, React unmounts the tree, and `DismissableLayer`'s `useEffect` cleanup should restore `body.pointerEvents`. But there's a race between unmount cleanup completing and the next story's play function starting. Sometimes cleanup wins (test passes), sometimes the play function wins (test fails). > >**[#26077]'s `pointerEventsCheck: Never`** works but is a workaround. It doesn't address the leaked state, and `UpdateUserRoleSuccess` itself could be flaky too (if whatever story precedes it leaves the same stale state). The other stories in the same file (Suspend, Delete, Activate, ResetPassword) all open Radix Dialogs too, so any of them could leak this state to the next story.