← All Reports

Automate User App — ENG-5352 QA Verification

Installations Page Scrollbar — Bug Verification (QA Review)

📅 2026-06-10 🌐 automate.dev.sense.engineering/installations 🤖 Claude Opus 4.7 + playwright-cli 👤 Paul Wagner
FAIL
Bug still reproduces
ENG-5352
Ticket under verification
QA Review
Ticket status entering
5
Viewport / zoom combos tested
6
Screenshots

🚨 Verdict — Bug NOT fixed, return to dev

The Installations page (/installations) does not provide a page-level scrollbar at small viewport heights. Instead, the PrimeNG datatable container (div.p-datatable-table-container) absorbs the height constraint and compresses to a fixed area with internal scrolling. At common zoom levels (100%, 125%, 150%) on a small viewport, the table content is either heavily compressed (1–3 rows) or completely hidden (just a header strip). The only way to see meaningful table content is to zoom the browser out — matching the workaround documented in the ticket.

Scope & Source of Truth

Ticket: ENG-5352 — [User App - Installations] Main page scrollbar intermittently disabled and cannot scroll to table content

Reporter: Abbi Melville — Status entering QA: QA Review — Sprint: Cloud Sprint 45

Source of truth: The bug's Expected Result section: "The page scrollbar remains functional at all supported zoom levels. Users can scroll normally to reach the table. Zooming in or out does not disable or hide the page scrollbar."

Method: Live verification against https://automate.dev.sense.engineering/installations after the developer marked the ticket QA Review. Resize the viewport / change zoom; inspect document.documentElement.scrollHeight vs clientHeight via JS evaluation, plus visual screenshots.

Test Matrix — Viewport / Zoom Combinations

#ViewportZoomPage scrollable?Table rows visibleVerdictEvidence
12048 × 1018100%No (fits)~12 rowsn/aDefault desktop — bug condition not present, included as baseline
21366 × 600100%No (does not overflow)3 rows + internal scrollFAILhtml.scrollHeight=600 === clientHeight=600. Page-level scrollbar absent. Internal table scrollbar only
31366 × 600125%No1 rowFAILTable compressed further; page still does not scroll
41366 × 600150%No0 rows (thin strip only)FAILTable content area collapsed to a few pixels; no rows visible, no page scrollbar
51366 × 60075%No~7 rowsn/aWorkaround confirmed — zoom-out makes table accessible (matches ticket workaround)
61280 × 400100%No (does not overflow)0 rows (thin strip only)FAILExtreme small height: heading, search, and pagination visible; table essentially invisible

Method note: Zoom was applied via document.body.style.zoom in the live browser to reliably simulate browser zoom in a headed Playwright session (Ctrl+= keyboard zoom does not propagate through Playwright's input layer). Effect on layout is equivalent to native Chrome zoom.

Root Cause Indicators (observational)

What the DOM measurements say

  • The single scrollable container on the page is div.p-datatable-table-container (PrimeNG datatable wrapper), which reports scrollHeight ≈ 2748 against a clamped clientHeight ≈ 214 at 1366×600.
  • document.documentElement and document.body both report scrollHeight === clientHeight at every tested small viewport — the document never overflows the viewport.
  • Computed overflow-y on html and body is visible — nothing is forcibly hiding scroll; the layout simply never needs to scroll because some ancestor of the table is height-clamped (likely a height:100% / 100vh flex chain).

Implication: The page layout uses a fixed-height container that hands all leftover vertical space to the table, instead of letting the page overflow and scroll. This is exactly the behaviour the ticket describes — users cannot reach the table by scrolling the page because the page never scrolls.

Reproduction Steps

  1. Open Chrome and log in to the User App (Automate).
  2. Navigate to Installations via the sidebar (3rd icon from top).
  3. Resize the browser so the viewport height is ≤ 600 px (e.g., 1366×600), or use a small laptop / external monitor with a short viewport.
  4. Observe the Installations page.
ExpectedActual
  • A page-level scrollbar appears on the right edge of the page.
  • Scrolling the page reveals the full table.
  • Behaviour is identical at supported zoom levels.
  • No page-level scrollbar is rendered (the document never overflows the viewport).
  • The table content area is compressed; only a few rows are visible at 100% zoom, fewer at 125%, and none at 150%.
  • An internal table scrollbar is present but is the only way to see the workflow list.
  • Zoom-out (≤ 75%) is required to make the table visibly usable.

Regression Findings

Console & network

  • Console errors: 0 errors during the run. 1 warning (intercomSettings.user_id is set to undefined) — pre-existing on the Sense apps, unrelated to ENG-5352.
  • Network failures: No 4xx / 5xx responses on automate.dev.sense.engineering during the verification window.

No regressions surfaced — this bug is purely a CSS / layout issue, not a data or API issue.

Recommendation

Return ticket to development. The layout should allow the page to overflow vertically when the content (heading + filter bar + table + pagination) exceeds the viewport height, so the browser provides a normal page scrollbar.

Concrete options the dev can consider:

  • Remove the height clamp on the table's ancestor chain so the document overflows naturally and the page-level scrollbar appears.
  • If keeping the height clamp is intentional for desktop, gate it behind a min-height media query so it only applies when the viewport is tall enough to host a useful internal table area (e.g., ≥ 800px).
  • Either approach should be regression-checked at 1280×400, 1366×600, and 1920×1080, and at zoom 75 / 100 / 125 / 150%.
↑