Skip to content

test(runner): sweep the example1 grid before asserting its numeric cells - #336

Open
danielzytohoc wants to merge 1 commit into
masterfrom
fix/starter-matrix-virtualized-columns
Open

test(runner): sweep the example1 grid before asserting its numeric cells#336
danielzytohoc wants to merge 1 commit into
masterfrom
fix/starter-matrix-virtualized-columns

Conversation

@danielzytohoc

@danielzytohoc danielzytohoc commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Context

The nightly starter compatibility matrix failed on 2026-09-09 (run 34299201725): matrix: example1 @ 17 [sandpack] and @ 18 red on all three attempts with numericFormat rendered 87% at 17/18, everything else green, and the Sep 8 run fully green.

This is a test defect, not a product one. The assertion added in c447344 reads the <td>s present in the DOM at the initial scroll position. #307 then removed width: 800 from example1 so the grid fills its container, which in the suite's Desktop Chrome viewport is a 624px preview pane holding four of the starter's 150px columns. Item Quality (the 87% cell) now sits past the rendered edge, and Handsontable's column virtualization decides whether its <td> exists at all:

  • 17.1.0 and 18.1.0: viewportColumnRenderingOffset: "auto" is a fixed 1 since 17.1.0, so only Item Name → Category are in the DOM. 87% is absent until the grid is scrolled.
  • 15.3.0 and 16.2.0: the older proportional auto still renders one more column, so 87 is found — as the last rendered column, by a hair.

Reproduced locally against prod with the Desktop Chrome device: at 18.1.0 the rendered set lacks 87% at scrollLeft: 0 and contains it after scrolling the master holder. The formatting itself is correct at every major.

Fix (spec only): sweep .ht_master .wtHolder across its full scrollWidth, accumulate the rendered cell text along the way, and assert over that union inside expect.poll, so a slower re-render costs a retry instead of a false failure. Putting a fixed width back in the starter is not an option: pipeline/starter-grid-width.test.mjs forbids it and it would bring the clipped-grid defect from #307 back. Nothing in examples/ or in Handsontable itself needs to change.

Types of changes

  • New example
  • Update to an existing example
  • README / documentation change
  • Demo runner (runner/) change
  • CI / tooling change

How was this verified?

  • The red evidence is the spec itself: without this change it fails at 17 and 18 in the linked run (3/3 attempts each) and in a local reproduction against prod.
  • With the change, the same tests against prod (sandpack engine, no container sessions involved):
    cd runner && E2E_BASE_URL=https://demos.handsontable.com E2E_STARTER_MATRIX=1 \
      pnpm exec playwright test e2e/starter-matrix.spec.ts -g "example1 @ (16|17|18)" --workers=2 --retries=0
    
    3 passed (9.7s). The sweep adds under 300ms per test.
  • No tsconfig in the repo covers e2e/, so an ad hoc tsc --noEmit with the tsconfig.base.json options was run on the spec: no errors inside the changed block. The file's pre-existing errors (missing @types/node, noUncheckedIndexedAccess on the version parsing) are untouched.
  • PR CI skips this spec by design (E2E_STARTER_MATRIX gate); after merge, a workflow_dispatch of E2E — starter compatibility matrix confirms it ahead of the 01:00 UTC nightly.

Checklist

  • New/renamed example: added to runner/config/frameworks.json — n/a, no example change
  • New example: added a row to the tables in README.md — n/a
  • Ran pnpm build (and pnpm dev) in the affected example/server-example locally — n/a, spec-only change

Related issue(s):

  1. Failed run: https://github.com/handsontable/examples/actions/runs/34299201725
  2. Follow-up to fix(examples): let the JavaScript and example1 starter grids fill their containers (DEV-2794) #307 (starter grid sizing) and the per-major numeric assertion introduced in c447344

Note

Low Risk
E2E test-only change in an opt-in matrix suite; no runtime or product behavior changes.

Overview
Fixes flaky example1 checks in the opt-in starter compatibility matrix (E2E_STARTER_MATRIX) that were failing on Handsontable 17 and 18 with missing 87% even though formatting is correct.

Instead of collecting cell text from whatever columns are in the DOM at scrollLeft: 0, the spec horizontally scrolls .ht_master .wtHolder across its full width, unions rendered values (with a short post-scroll wait for Walkontable), and uses expect.poll + toContain for each expected formatted value from example1NumericCells. That avoids false negatives when the preview pane is narrower than the grid and column virtualization omits off-screen columns.

Spec-only; no starter or Handsontable product changes.

Reviewed by Cursor Bugbot for commit f91d9cb. Bugbot is set up for automated code reviews on this repo. Configure here.

The nightly starter matrix went red on `example1 @ 17` and `@ 18` with
"numericFormat rendered 87%". The assertion read only the <td>s in the
DOM at the initial scroll position, and once #307 let the starter fill
its container, the Item Quality column sits past the rendered edge of
the 624px preview pane. Handsontable virtualizes columns, and from
17.1.0 `viewportColumnRenderingOffset: "auto"` renders exactly one
column beyond the viewport, so the cell was never in the DOM to be read.
15 and 16 still render it by a hair, which is why they stayed green.

Scroll the master holder across its full scroll width and assert over
the union of everything rendered along the way, inside `expect.poll` so
a slow re-render costs a retry rather than a false failure. The numeric
formatting itself was never wrong: `87%` renders at 17.1.0 and 18.1.0
once the column is scrolled in.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants