Repository navigation
FE-2013: Wait for controls inside an opening Collapse to be fully shown before clicking - #10077
Conversation
…hown before clicking
A control inside a `Collapse` that is still opening is visible and stable
to Playwright while the `Collapse` clips it. The click scrolls the
clipping wrapper to reach the control, the wrapper scrolls back as it
grows, and the pointer event lands beside the control.
`expectFullyShown` waits until `toBeInViewport({ ratio: 1 })` passes,
which happens only once no ancestor clips the element. The PDF and DOCX
search tests, the parent-card remove button, and the sidebar entity type
item now wait for it before clicking. The PDF search test also asserts
that the result counter moves from "1 of 2" to "2 of 2".
|
The latest updates on your projects. Learn more about Vercel for GitHub.
3 Skipped Deployments
|
PR SummaryLow Risk Overview Specs now call it before interacting with controls inside opening collapses: sidebar Document link after expanding Entities, remove-parent on entity type cards, and PDF/DOCX preview search input and Next result. The PDF search test also asserts the result counter moves from 1 of 2 to 2 of 2. Reviewed by Cursor Bugbot for commit 15835b2. Bugbot is set up for automated code reviews on this repo. Configure here. |
There was a problem hiding this comment.
🟢 Approval recommended
The focused test-only changes address animation clipping, with no unresolved blocking findings.
No open issues 🎉
What changed in this PR
Stabilizes Playwright tests by waiting for controls inside opening Collapse components to be fully shown before interacting.
Changes:
- Adds a shared full-visibility assertion.
- Applies waits to document search, parent removal, and sidebar navigation.
- Adds PDF search-result count assertions.
| File | Description |
|---|---|
| tests/hash-playwright/tests/shared/expect-fully-shown.ts | Adds the reusable viewport assertion. |
| tests/hash-playwright/tests/features/file-preview/pdf.spec.ts | Waits for search controls and verifies result counts. |
| tests/hash-playwright/tests/features/file-preview/docx.spec.ts | Waits before interacting with search controls. |
| tests/hash-playwright/tests/features/entity-type-editing.spec.ts | Waits for the parent removal button. |
| tests/hash-playwright/tests/features/entities-page.spec.ts | Waits for the sidebar Document item. |
Review effort: Balanced
Requested by Tim Diekmann · Slack thread
🌟 Purpose
The PDF preview search test failed in CI because it clicked Next result about 124 ms into the search box's opening animation. The button sits inside two nested horizontal
Collapses that clip it until they finish. Playwright judged it visible and stable, since the wrapper clips the button without moving it. The click then scrolled the clipped wrappers sideways to reach the button. As the wrappers grew, they scrolled back and the button slid out from under the pointer.onClicknever ran: the counter stayed at "1 of 2" and the page stayed on page 1.This PR makes the tests wait until such a control is fully shown before clicking it. It applies the wait to every spec found clicking a control inside an opening
Collapse.🔍 Changes
expectFullyShownintests/shared/expect-fully-shown.tswrapstoBeInViewport({ ratio: 1 }). In Playwright 1.58.2 the check readsintersectionRatiofrom anIntersectionObserverwith the viewport as root. The spec clips that intersection by every ancestor withoverflowother thanvisible, so the ratio reaches 1 only once theCollapsewrappers stop clipping the element. The check does not scroll, so it sees the natural layout.filldoes not scroll the outer wrapper while it opens. Then wait for Next result, click it, and assert the counter moves from "1 of 2" to "2 of 2". The PDF test previously asserted neither count.entity-type-editing.spec.ts: the parent card's remove button sits in a horizontalCollapsethat opens on hover (TypeCard), the same pattern as the search box. It now waits before clicking.entities-page.spec.ts: the sidebar entity type item sits in nested verticalCollapses (the section and the item'sTransitionGroupentry). WhenexpandSidebarSectionopens the section, the click can hit the same scroll-back. It now waits before clicking.Other clicks after an opening transition were judged safe and left alone:
types-pageweb filter, rowOptions for …menu, account dropdownSettings/Sign Out): MUIMenuusesGrow, which scales the paper. The item's box changes every frame, so Playwright's stability check already waits for the animation to end. Nothing clips the item.selector-autocomplete-option, type selectoroption): the popper has no transition.Modal:Fadechanges only opacity. The button neither moves nor gets clipped.create-entity-type-btn: in the section header, outside theCollapse.toBeInViewportalso needs the element inside the browser viewport. The sidebar's Document item is expected near the top of the list. If a seed change ever pushes it below the fold, that assertion fails every time rather than intermittently.Generated by Claude Code