@kinetixui/ui 0.23.2 → 0.24.0

package/src/components-overlay.test.tsx

@@ -0,0 +1,381 @@
+import * as React from "react";
+import { render, screen, waitFor } from "@testing-library/react";
+import userEvent from "@testing-library/user-event";
+import { describe, expect, it, vi } from "vitest";
+import { KinetixDirectionProvider } from "./components/direction-provider";
+import { Drawer, DrawerClose, DrawerContent, DrawerDescription, DrawerTitle, DrawerTrigger } from "./components/drawer";
+import { Popover, PopoverContent, PopoverTrigger } from "./components/popover";
+import { Dialog, DialogContent, DialogDescription, DialogTitle, DialogTrigger } from "./components/dialog";
+import {
+  DropdownMenu,
+  DropdownMenuContent,
+  DropdownMenuItem,
+  DropdownMenuSub,
+  DropdownMenuSubContent,
+  DropdownMenuSubTrigger,
+  DropdownMenuTrigger,
+} from "./components/dropdown-menu";
+import { Sheet, SheetContent, SheetDescription, SheetTitle, SheetTrigger } from "./components/sheet";
+import { Modal } from "./components/modal";
+import { Tooltip, TooltipContent, TooltipProvider, TooltipTrigger } from "./components/tooltip";
+
+/**
+ * components-overlay.test.tsx — the overlay family's open/close state contract, and the two defects the
+ * open-state scan found.
+ *
+ * Separate from `components-keyboard.test.tsx` for one reason worth stating: that file is the single
+ * source `scripts/gen-keyboard.mjs` publishes each component's keyboard model from, so what belongs there
+ * is keyboard behaviour. Controlled-vs-uncontrolled open state, a `role="dialog"` having a name, and
+ * where focus lands are not keyboard models, and documenting them as one would misdescribe them.
+ *
+ * `Drawer` also has to live outside that module. Radix's anchored ContextMenu stops opening once any
+ * modal overlay has mounted there, and vaul's Drawer is one — the ordering constraint is recorded at the
+ * top of the ContextMenu suite in that file.
+ *
+ * kx-verify: interaction
+ */
+
+describe("Popover's accessible name", () => {
+  it("names the dialog Radix gives it, because an unnamed one announces only its role", async () => {
+    const user = userEvent.setup();
+    render(
+      <Popover>
+        <PopoverTrigger>Open</PopoverTrigger>
+        <PopoverContent>
+          <p>Dimensions</p>
+        </PopoverContent>
+      </Popover>,
+    );
+    await user.click(screen.getByRole("button", { name: "Open" }));
+    // Found by running axe against the open surface — a check that did not exist before this slice,
+    // because the suite scanned overlay stories closed. Every Popover in the library was a dialog with
+    // no accessible name, which WCAG 4.1.2 fails and a screen reader reads as the single word "dialog".
+    expect(await screen.findByRole("dialog", { name: "Popover" })).toBeInTheDocument();
+  });
+
+  it("keeps the caller's own name, and stays out of the way of aria-labelledby", async () => {
+    const user = userEvent.setup();
+    const { unmount } = render(
+      <Popover>
+        <PopoverTrigger>A</PopoverTrigger>
+        <PopoverContent aria-label="Layer dimensions">
+          <p>x</p>
+        </PopoverContent>
+      </Popover>,
+    );
+    await user.click(screen.getByRole("button", { name: "A" }));
+    expect(await screen.findByRole("dialog", { name: "Layer dimensions" })).toBeInTheDocument();
+    unmount();
+
+    render(
+      <Popover>
+        <PopoverTrigger>B</PopoverTrigger>
+        <PopoverContent aria-labelledby="heading">
+          <h2 id="heading">Dimensions</h2>
+        </PopoverContent>
+      </Popover>,
+    );
+    await user.click(screen.getByRole("button", { name: "B" }));
+    const named = await screen.findByRole("dialog", { name: "Dimensions" });
+    // The fallback must not shadow a heading the caller pointed at: an aria-label would win over
+    // aria-labelledby and the name would silently become "Popover" again.
+    expect(named).not.toHaveAttribute("aria-label");
+  });
+
+  it("survives the ordinary conditional-prop spelling, where the name arrives as undefined", async () => {
+    const user = userEvent.setup();
+    const label: string | undefined = undefined;
+    render(
+      <Popover>
+        <PopoverTrigger>C</PopoverTrigger>
+        {/* `aria-label={maybe}` is how a caller passes an optional name, and it puts the key in props
+            with the value undefined. Read off a spread props object, that undefined is spread back over
+            the computed fallback and DELETES the attribute — so the unnamed dialog this fallback exists
+            to prevent comes back through the most ordinary call site there is. */}
+        <PopoverContent aria-label={label}>
+          <p>x</p>
+        </PopoverContent>
+      </Popover>,
+    );
+    await user.click(screen.getByRole("button", { name: "C" }));
+    expect(await screen.findByRole("dialog", { name: "Popover" })).toBeInTheDocument();
+  });
+});
+
+describe("Drawer focus entry", () => {
+  function Example() {
+    return (
+      <Drawer>
+        <DrawerTrigger>Open Drawer</DrawerTrigger>
+        <DrawerContent>
+          <DrawerTitle>Move goal</DrawerTitle>
+          <DrawerDescription>Set your daily activity goal.</DrawerDescription>
+          <DrawerClose>Cancel</DrawerClose>
+        </DrawerContent>
+      </Drawer>
+    );
+  }
+
+  it("moves focus into the panel, and not onto the trigger the drawer has just hidden", async () => {
+    const user = userEvent.setup();
+    render(<Example />);
+    const trigger = screen.getByRole("button", { name: "Open Drawer" });
+    await user.click(trigger);
+    const panel = await screen.findByRole("dialog");
+
+    // Measured in Chromium before this was fixed: focus stayed on the trigger, which by then sits inside
+    // a subtree the drawer marks aria-hidden — so a screen-reader user was left on an element their
+    // software had just been told does not exist. The panel itself is the destination rather than the
+    // first control in it, so a drawer containing a field does not summon a mobile keyboard on open.
+    await waitFor(() => expect(document.activeElement).toBe(panel));
+    expect(trigger).not.toHaveFocus();
+  });
+
+  it("still enters the panel when the caller also listens for the open-focus event", async () => {
+    const user = userEvent.setup();
+    const seen = vi.fn();
+    render(
+      <Drawer>
+        <DrawerTrigger>Open Drawer</DrawerTrigger>
+        {/* A consumer handler that only observes. With `{...props}` trailing it would REPLACE the one
+            this component installs, and because vaul suppresses auto-focus otherwise, focus would be left
+            on the trigger the drawer has just hidden — the defect back, via a prop that does nothing. */}
+        <DrawerContent onOpenAutoFocus={seen}>
+          <DrawerTitle>Move goal</DrawerTitle>
+          <DrawerClose>Cancel</DrawerClose>
+        </DrawerContent>
+      </Drawer>,
+    );
+    await user.click(screen.getByRole("button", { name: "Open Drawer" }));
+    const panel = await screen.findByRole("dialog");
+    await waitFor(() => expect(document.activeElement).toBe(panel));
+    expect(seen).toHaveBeenCalledTimes(1);
+  });
+
+  it("leaves focus to a caller who takes it over deliberately", async () => {
+    const user = userEvent.setup();
+    render(
+      <Drawer>
+        <DrawerTrigger>Open Drawer</DrawerTrigger>
+        {/* Calling preventDefault is how a caller says they are placing focus themselves. Composition has
+            to mean composition and not "ours always wins", or an author who wants focus on their own
+            control cannot have it. */}
+        <DrawerContent
+          onOpenAutoFocus={(event) => {
+            event.preventDefault();
+            document.getElementById("mine")?.focus();
+          }}
+        >
+          <DrawerTitle>Move goal</DrawerTitle>
+          <button id="mine" type="button">
+            Mine
+          </button>
+        </DrawerContent>
+      </Drawer>,
+    );
+    await user.click(screen.getByRole("button", { name: "Open Drawer" }));
+    await screen.findByRole("dialog");
+    await waitFor(() => expect(screen.getByRole("button", { name: "Mine" })).toHaveFocus());
+  });
+
+  it("closes on Escape and gives focus back", async () => {
+    const user = userEvent.setup();
+    render(<Example />);
+    const trigger = screen.getByRole("button", { name: "Open Drawer" });
+    await user.click(trigger);
+    await screen.findByRole("dialog");
+    await user.keyboard("{Escape}");
+    await waitFor(() => expect(screen.queryByRole("dialog")).not.toBeInTheDocument());
+    expect(trigger).toHaveFocus();
+  });
+});
+
+describe("Overlay open state", () => {
+  it("Dialog stays closed when controlled, and reports the request once", async () => {
+    const user = userEvent.setup();
+    const onOpenChange = vi.fn();
+    render(
+      <Dialog open={false} onOpenChange={onOpenChange}>
+        <DialogTrigger>Open</DialogTrigger>
+        <DialogContent>
+          <DialogTitle>T</DialogTitle>
+          <DialogDescription>D</DialogDescription>
+        </DialogContent>
+      </Dialog>,
+    );
+    await user.click(screen.getByRole("button", { name: "Open" }));
+    expect(onOpenChange).toHaveBeenCalledExactlyOnceWith(true);
+    // Controlled means controlled: the surface must not appear on its own.
+    expect(screen.queryByRole("dialog")).toBeNull();
+  });
+
+  it("Dialog opens from defaultOpen and can be closed and reopened", async () => {
+    const user = userEvent.setup();
+    render(
+      <Dialog defaultOpen>
+        <DialogTrigger>Open</DialogTrigger>
+        <DialogContent>
+          <DialogTitle>Reopenable</DialogTitle>
+          <DialogDescription>D</DialogDescription>
+        </DialogContent>
+      </Dialog>,
+    );
+    await screen.findByRole("dialog", { name: "Reopenable" });
+    await user.keyboard("{Escape}");
+    await waitFor(() => expect(screen.queryByRole("dialog")).toBeNull());
+
+    // Reopening is the half that stale state breaks, so it is the half worth asserting.
+    await user.click(screen.getByRole("button", { name: "Open" }));
+    expect(await screen.findByRole("dialog", { name: "Reopenable" })).toBeInTheDocument();
+  });
+
+  it("Sheet's close button dismisses it and returns focus", async () => {
+    const user = userEvent.setup();
+    render(
+      <Sheet>
+        <SheetTrigger>Open</SheetTrigger>
+        <SheetContent>
+          <SheetTitle>Panel</SheetTitle>
+          <SheetDescription>D</SheetDescription>
+        </SheetContent>
+      </Sheet>,
+    );
+    const trigger = screen.getByRole("button", { name: "Open" });
+    await user.click(trigger);
+    await screen.findByRole("dialog", { name: "Panel" });
+
+    await user.click(screen.getByRole("button", { name: "Close" }));
+    await waitFor(() => expect(screen.queryByRole("dialog")).toBeNull());
+    expect(trigger).toHaveFocus();
+  });
+
+  it("Modal's own buttons carry its decisions, and each fires once", async () => {
+    const user = userEvent.setup();
+    const onAction = vi.fn();
+    const onCancel = vi.fn();
+    render(
+      <Modal
+        type="Confirmation"
+        title="Confirm it"
+        description="Sure?"
+        trigger={<button>Go</button>}
+        onAction={onAction}
+        onCancel={onCancel}
+      />,
+    );
+    await user.click(screen.getByRole("button", { name: "Go" }));
+    await screen.findByRole("dialog", { name: "Confirm it" });
+    await user.click(screen.getByRole("button", { name: "Cancel" }));
+    expect(onCancel).toHaveBeenCalledOnce();
+    expect(onAction).not.toHaveBeenCalled();
+    await waitFor(() => expect(screen.queryByRole("dialog")).toBeNull());
+
+    await user.click(screen.getByRole("button", { name: "Go" }));
+    await screen.findByRole("dialog", { name: "Confirm it" });
+    await user.click(screen.getByRole("button", { name: "Confirm" }));
+    expect(onAction).toHaveBeenCalledOnce();
+    expect(onCancel).toHaveBeenCalledOnce(); // still once: confirming is not cancelling
+  });
+
+  it("Popover closes on Escape and hands focus back, without trapping it the way a dialog does", async () => {
+    const user = userEvent.setup();
+    render(
+      <>
+        <Popover>
+          <PopoverTrigger>Open</PopoverTrigger>
+          <PopoverContent aria-label="Panel">
+            <button>Inside</button>
+          </PopoverContent>
+        </Popover>
+        <button>After</button>
+      </>,
+    );
+    const trigger = screen.getByRole("button", { name: "Open" });
+    await user.click(trigger);
+    const surface = await screen.findByRole("dialog", { name: "Panel" });
+    // Non-modal, so `openStates` declares `modal: false` and a11y-browser asserts there that Tab can
+    // leave it. That half is deliberately not asserted here: in jsdom focus stays on the one control
+    // inside the surface however many times Tab is pressed, which is the focus scope's loop behaving
+    // differently without layout, not the component trapping. A browser answers it; this cannot.
+    expect(surface).toBeInTheDocument();
+
+    await user.keyboard("{Escape}");
+    await waitFor(() => expect(screen.queryByRole("dialog")).toBeNull());
+    expect(trigger).toHaveFocus();
+  });
+
+  it("Tooltip does not trap focus either, and closes on Escape", async () => {
+    const user = userEvent.setup();
+    render(
+      <TooltipProvider>
+        <Tooltip>
+          <TooltipTrigger>Library</TooltipTrigger>
+          <TooltipContent>Add to library</TooltipContent>
+        </Tooltip>
+      </TooltipProvider>,
+    );
+    await user.tab();
+    await waitFor(() => expect(screen.getByRole("tooltip")).toBeInTheDocument());
+    await user.keyboard("{Escape}");
+    await waitFor(() => expect(screen.queryByRole("tooltip")).not.toBeInTheDocument());
+  });
+});
+
+// kx-verify: interaction, rtl
+
+describe("Overlay portals under RTL", () => {
+  const rtl = (node: React.ReactNode) => <KinetixDirectionProvider dir="rtl">{node}</KinetixDirectionProvider>;
+
+  it("resolves a submenu onto the start side, which is the direction reaching the portal", async () => {
+    const user = userEvent.setup();
+    function Example() {
+      return (
+        <DropdownMenu>
+          <DropdownMenuTrigger>Actions</DropdownMenuTrigger>
+          <DropdownMenuContent>
+            <DropdownMenuSub>
+              <DropdownMenuSubTrigger>More</DropdownMenuSubTrigger>
+              <DropdownMenuSubContent>
+                <DropdownMenuItem>Nested</DropdownMenuItem>
+              </DropdownMenuSubContent>
+            </DropdownMenuSub>
+          </DropdownMenuContent>
+        </DropdownMenu>
+      );
+    }
+    render(rtl(<Example />));
+    screen.getByRole("button", { name: "Actions" }).focus();
+    await user.keyboard("{Enter}");
+    await screen.findByRole("menu");
+
+    // The submenu is portaled out of the provider's subtree, so nothing in the DOM carries the direction
+    // to it — CSS inheritance cannot, because the portal is a child of <body>. What does reach it is
+    // Radix's direction context, and this is the observable consequence: a submenu that opens toward the
+    // inline start resolves `data-side="left"`, where under LTR it resolves "right". The computed CSS
+    // `direction` on portal content is a different claim and belongs to the browser pass, which sets
+    // `dir` on the document the way an RTL app does.
+    screen.getByRole("menuitem", { name: "More" }).focus();
+    await user.keyboard("{ArrowLeft}");
+    const nested = await screen.findByRole("menuitem", { name: "Nested" });
+    const sub = nested.closest('[role="menu"]');
+    expect(sub?.getAttribute("data-side")).toBe("left");
+  });
+
+  it("keeps Popover's fallback name when the surface is portaled under RTL", async () => {
+    const user = userEvent.setup();
+    render(
+      rtl(
+        <Popover>
+          <PopoverTrigger>افتح</PopoverTrigger>
+          <PopoverContent>
+            <p>المحتوى</p>
+          </PopoverContent>
+        </Popover>,
+      ),
+    );
+    await user.click(screen.getByRole("button", { name: "افتح" }));
+    // The name has to survive the portal and the direction both, or an RTL app gets the unnamed dialog
+    // back without anything saying so.
+    expect(await screen.findByRole("dialog", { name: "Popover" })).toBeInTheDocument();
+  });
+});

package/src/components-rtl.test.tsx

@@ -0,0 +1,258 @@
+import * as React from "react";
+import { fireEvent, render, screen } from "@testing-library/react";
+import userEvent from "@testing-library/user-event";
+import { describe, expect, it } from "vitest";
+import { KinetixDirectionProvider } from "./components/direction-provider";
+import {
+  ContextMenu,
+  ContextMenuCheckboxItem,
+  ContextMenuContent,
+  ContextMenuItem,
+  ContextMenuShortcut,
+  ContextMenuSub,
+  ContextMenuSubContent,
+  ContextMenuSubTrigger,
+  ContextMenuTrigger,
+} from "./components/context-menu";
+import {
+  Menubar,
+  MenubarContent,
+  MenubarItem,
+  MenubarMenu,
+  MenubarShortcut,
+  MenubarTrigger,
+} from "./components/menubar";
+import {
+  NavigationMenu,
+  NavigationMenuContent,
+  NavigationMenuItem,
+  NavigationMenuList,
+  NavigationMenuTrigger,
+} from "./components/navigation-menu";
+import { Popover, PopoverContent, PopoverTrigger } from "./components/popover";
+import { Tooltip, TooltipContent, TooltipProvider, TooltipTrigger } from "./components/tooltip";
+import {
+  AlertDialog,
+  AlertDialogContent,
+  AlertDialogDescription,
+  AlertDialogAction,
+  AlertDialogCancel,
+  AlertDialogFooter,
+  AlertDialogHeader,
+  AlertDialogTitle,
+} from "./components/alert-dialog";
+
+/**
+ * components-rtl.test.tsx — the overlay family mirrors under `dir="rtl"`.
+ *
+ * Slice 2 of the RTL conversion (see RTL.md). Slice 1 converted Dialog, Sheet, Drawer, DropdownMenu and
+ * Select; this covers the rest of the overlay family — ContextMenu, Menubar, AlertDialog, NavigationMenu,
+ * Popover and Tooltip.
+ *
+ * `scripts/check-rtl.mjs` is a source guardrail: it proves no physical-direction class is left in the file.
+ * It cannot prove the class that replaced it is the *right* one, or that the Radix primitive underneath
+ * actually flips — which is the failure RTL.md records as the one that cost a slice to find. These are the
+ * behavioural half: the rendered DOM carries the logical class, and the keyboard direction mirrors.
+ *
+ * jsdom has no layout, so these assert the contract (class names, direction-dependent key handling) rather
+ * than measured geometry. Pixel mirroring is the browser pass's job.
+ *
+ * kx-verify: rtl
+ */
+
+const rtl = (node: React.ReactNode) => <KinetixDirectionProvider dir="rtl">{node}</KinetixDirectionProvider>;
+
+describe("ContextMenu under RTL", () => {
+  function Example() {
+    return (
+      <ContextMenu>
+        <ContextMenuTrigger>target</ContextMenuTrigger>
+        <ContextMenuContent>
+          <ContextMenuItem inset>Inset item</ContextMenuItem>
+          <ContextMenuCheckboxItem checked>Checked</ContextMenuCheckboxItem>
+          <ContextMenuItem>
+            Save <ContextMenuShortcut>⌘S</ContextMenuShortcut>
+          </ContextMenuItem>
+          <ContextMenuSub>
+            <ContextMenuSubTrigger>More</ContextMenuSubTrigger>
+            <ContextMenuSubContent>
+              <ContextMenuItem>Nested</ContextMenuItem>
+            </ContextMenuSubContent>
+          </ContextMenuSub>
+        </ContextMenuContent>
+      </ContextMenu>
+    );
+  }
+
+  it("mirrors its gutters, shortcut and submenu direction", async () => {
+    // One open, many assertions: Radix's ContextMenu is driven by a real contextmenu event and does not
+    // re-open cleanly across renders in jsdom, so re-opening per assertion would be testing the harness.
+    const user = userEvent.setup();
+    render(rtl(<Example />));
+    fireEvent.contextMenu(screen.getByText("target"));
+    await screen.findByRole("menu");
+
+    // Inset items indent on the inline start, not the physical left.
+    expect(screen.getByText("Inset item")).toHaveClass("ps-8");
+    expect(screen.getByText("Inset item").className).not.toMatch(/\bpl-8\b/);
+
+    // The tick gutter must move to the right-hand side under RTL.
+    const checkbox = screen.getByRole("menuitemcheckbox", { name: /Checked/ });
+    expect(checkbox.querySelector(".start-2")).not.toBeNull();
+    expect(checkbox.querySelector(".left-2")).toBeNull();
+
+    // The shortcut pushes to the inline end.
+    expect(screen.getByText("⌘S")).toHaveClass("ms-auto");
+
+    // In a right-to-left menu the submenu unfolds toward the left, so ArrowLeft is "into" it.
+    const sub = screen.getByRole("menuitem", { name: "More" });
+    sub.focus();
+    await user.keyboard("{ArrowLeft}");
+    expect(await screen.findByRole("menuitem", { name: "Nested" })).toBeInTheDocument();
+  });
+});
+
+describe("Menubar under RTL", () => {
+  it("places the shortcut on the inline end", async () => {
+    const user = userEvent.setup();
+    render(
+      rtl(
+        <Menubar>
+          <MenubarMenu>
+            <MenubarTrigger>File</MenubarTrigger>
+            <MenubarContent>
+              <MenubarItem inset>
+                New <MenubarShortcut>⌘N</MenubarShortcut>
+              </MenubarItem>
+            </MenubarContent>
+          </MenubarMenu>
+        </Menubar>,
+      ),
+    );
+    const trigger = screen.getByRole("menuitem", { name: "File" });
+    trigger.focus();
+    await user.keyboard("{Enter}");
+    await screen.findByRole("menu");
+    expect(screen.getByText("⌘N")).toHaveClass("ms-auto");
+    expect(screen.getByRole("menuitem", { name: /New/ })).toHaveClass("ps-8");
+  });
+});
+
+describe("AlertDialog under RTL", () => {
+  it("aligns its header to the reading direction and stays centred", () => {
+    const { container } = render(
+      rtl(
+        <AlertDialog open>
+          <AlertDialogContent>
+            <AlertDialogHeader>
+              <AlertDialogTitle>Delete</AlertDialogTitle>
+              <AlertDialogDescription>This cannot be undone.</AlertDialogDescription>
+            </AlertDialogHeader>
+          </AlertDialogContent>
+        </AlertDialog>,
+      ),
+    );
+    const header = screen.getByText("Delete").parentElement!;
+    expect(header).toHaveClass("sm:text-start");
+    expect(header.className).not.toMatch(/sm:text-left/);
+
+    // The centring trick stays physical on purpose — it must not have been "converted" to start-1/2,
+    // which would read as mirroring while landing in the same place.
+    const content = screen.getByRole("alertdialog");
+    expect(content.className).toMatch(/\bleft-1\/2\b/);
+    expect(content.className).not.toMatch(/\bstart-1\/2\b/);
+    expect(container).toBeTruthy();
+  });
+
+  it("spaces its footer buttons with a direction-agnostic gap", () => {
+    render(
+      rtl(
+        <AlertDialog open>
+          <AlertDialogContent>
+            <AlertDialogTitle>Delete</AlertDialogTitle>
+            <AlertDialogDescription>This cannot be undone.</AlertDialogDescription>
+            <AlertDialogFooter>
+              <AlertDialogCancel>Cancel</AlertDialogCancel>
+              <AlertDialogAction>Delete</AlertDialogAction>
+            </AlertDialogFooter>
+          </AlertDialogContent>
+        </AlertDialog>,
+      ),
+    );
+    const footer = screen.getByRole("button", { name: "Cancel" }).parentElement!;
+    // `space-x-*` compiles to a physical margin-left, so under RTL it lands on the outside of the
+    // pair and the two buttons touch. `gap` has no side.
+    expect(footer).toHaveClass("gap-2");
+    expect(footer.className).not.toMatch(/space-x-/);
+  });
+});
+
+describe("NavigationMenu under RTL", () => {
+  it("anchors its panel and chevron gap on the inline axis", async () => {
+    const user = userEvent.setup();
+    render(
+      rtl(
+        <NavigationMenu>
+          <NavigationMenuList>
+            <NavigationMenuItem>
+              <NavigationMenuTrigger>Products</NavigationMenuTrigger>
+              <NavigationMenuContent>
+                <div>Panel</div>
+              </NavigationMenuContent>
+            </NavigationMenuItem>
+          </NavigationMenuList>
+        </NavigationMenu>,
+      ),
+    );
+    const trigger = screen.getByRole("button", { name: /Products/ });
+    // The disclosure chevron is spaced from the label on the inline axis.
+    expect(trigger.querySelector(".ms-1")).not.toBeNull();
+    expect(trigger.querySelector(".ml-1")).toBeNull();
+
+    await user.click(trigger);
+    const panel = (await screen.findByText("Panel")).parentElement!;
+    expect(panel.className).toMatch(/\bstart-0\b/);
+    expect(panel.className).not.toMatch(/\bleft-0\b/);
+  });
+});
+
+/**
+ * Popover and Tooltip are the other half of the contract: their entry animation keys off `data-side`,
+ * which Radix has already resolved to a PHYSICAL side after flipping for direction and collisions. A
+ * well-meaning conversion to logical classes there would invert the animation under RTL, so these assert
+ * the physical classes are deliberately retained.
+ */
+describe("Popover and Tooltip keep their resolved-side animation physical", () => {
+  it("Popover slides away from the trigger on the side Radix resolved", async () => {
+    const user = userEvent.setup();
+    render(
+      rtl(
+        <Popover>
+          <PopoverTrigger>Open</PopoverTrigger>
+          <PopoverContent>Body</PopoverContent>
+        </Popover>,
+      ),
+    );
+    await user.click(screen.getByRole("button", { name: "Open" }));
+    const content = await screen.findByText("Body");
+    expect(content.className).toMatch(/data-\[side=left\]:slide-in-from-right-2/);
+    expect(content.className).toMatch(/data-\[side=right\]:slide-in-from-left-2/);
+  });
+
+  it("Tooltip does the same", async () => {
+    const user = userEvent.setup();
+    render(
+      rtl(
+        <TooltipProvider delayDuration={0}>
+          <Tooltip>
+            <TooltipTrigger>Hover</TooltipTrigger>
+            <TooltipContent>Hint</TooltipContent>
+          </Tooltip>
+        </TooltipProvider>,
+      ),
+    );
+    await user.hover(screen.getByRole("button", { name: "Hover" }));
+    const tip = (await screen.findAllByText("Hint"))[0];
+    expect(tip.className).toMatch(/data-\[side=left\]:slide-in-from-right-2/);
+  });
+});