Skip to content

Update expected UI screenshots for the new headless Chrome (Node 24 / Puppeteer 24)#327

Draft
sgiehl wants to merge 8 commits into
prepare6xfrom
dev-20341
Draft

Update expected UI screenshots for the new headless Chrome (Node 24 / Puppeteer 24)#327
sgiehl wants to merge 8 commits into
prepare6xfrom
dev-20341

Conversation

@sgiehl

@sgiehl sgiehl commented Jul 21, 2026

Copy link
Copy Markdown
Member

Updates the expected UI test screenshots for the new headless Chrome used by the modernized screenshot-testing harness (Node 24 / Puppeteer 24).

This is the submodule counterpart of the core migration PR and must be merged together with it:
matomo-org/matomo#24677

The screenshot changes are rendering drift from the new headless Chrome (identical content, minor line-height/anti-aliasing shifts); each was reviewed against the previous expected before syncing.

Checklist

  • [✔] I have understood, reviewed, and tested all AI outputs before use
  • [✔] All AI instructions respect security, IP, and privacy rules

sgiehl added 7 commits July 21, 2026 08:40
Scroll the toggle to the viewport centre before clicking; under Chrome 149 it
could otherwise be reported as 'not clickable' when behind a sticky header.
page.click() reports the Materialize lever as not clickable on the new Chrome
even after scrolling it into view; dispatching the click directly fires the
toggle handler reliably.
After enabling the queue toggle the submit opens a password-confirmation modal;
under the modern headless Chrome its input is not focusable and its confirm
button not clickable until the open animation finishes. Wait for them to be
visible and use a JS click for the confirm button.
page/element click can be reported as not clickable under the modern headless
Chrome, so the password-confirmation modal never opened; dispatch the click
directly to trigger it reliably.
Three Chrome-149 issues stacked in this test: the queue toggle was clicked via
its label span (which no longer reliably flips the checkbox), so the setting
never changed; and the password-confirmation modal selectors were unscoped, so
they matched a closed .confirm-password-modal instance instead of the open one.
Click the checkbox input directly, JS-click the submit button, and scope all
modal interactions to .modal.open. Verified locally: the redis connection error
is now shown as expected.
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.

1 participant