chore(deps-dev): bump to playwright with new firefox version

[maverbiest]

Clone of #7007 to see if Firefox integration test flakiness can be addressed.

Dependabot is trying to bump playwright from 1.61.1 to 1.62.1, which has Firefox version 153.0 (was 151.0 before: https://github.com/microsoft/playwright/releases).

The integration test for Firefox failed repeatedly and unpredictably on that branch on testing steps that create a new user through the Auth page, specifically when trying to check the 'I agree' check box (screenshots below). There is a playwright issue where people report clicking checkboxes in playwright as a source of flakiness (though not all exactly the same problem, see microsoft/playwright#13470)

This PR wraps the this.page.getByLabel('I agree').check() in an expect(...).toPass() so it retries. While this does seem to resolve flakiness, the underlying cause is still not clear to me. Especially because we have different checkboxes that are check()-ed without retrying in the integration tests where this issue doesn't arise (although those are not in the keycloakify page).

Screenshots

Error message in CI logs of #7007

Playwright screenshots

Action:

The error logs:

Error: locator.check: Clicking the checkbox did not change its state
Call log:
  - waiting for getByLabel('I agree')
    - locator resolved to <input type="checkbox" id="termsAccepted" name="termsAccepted" aria-invalid="false" class="kcCheckboxInputClass"/>
  - attempting click action
    - waiting for element to be visible, enabled and stable
    - element is visible, enabled and stable
    - scrolling into view if needed
    - done scrolling
    - performing click action
    - click action done
    - waiting for scheduled navigations to finish
    - navigations have finished

Before:

After:

(the blue square that's added seems to be locator added by playwright, not the actual page, __playwright_target__ marker)

PR Checklist

• All necessary documentation has been adapted.
• The implemented feature is covered by appropriate, automated tests.
• Any manual testing that has been done is documented (i.e. what exactly was tested?)

🚀 Preview: Add preview label to enable

[claude]

This PR may be related to Firefox integration test issues: #5555, #5677, #4535

[claude]

Claude finished @maverbiest's task in 1m 17s —— View job

---

Claude's Review

• Gather context (PR diff, files changed)
• Review integration-tests/tests/pages/auth.page.ts change
• Review package.json / package-lock.json bump
• Post review feedback

Summary

This is a small, well-scoped fix: bumps @playwright/test (and related dev deps) from 1.61.1 → 1.62.1 in integration-tests/package.json/package-lock.json, and wraps the flaky I agree checkbox interaction in auth.page.ts with expect(...).toPass({ timeout: 10_000 }) to retry it against the new bundled Firefox (153.0).

Observations

• auth.page.ts:36-38: The retry wrapper is a reasonable, low-risk mitigation for the flake — it doesn't mask a real product bug, just retries a UI interaction that appears to intermittently fail to register in the newer Firefox build. expect was already imported, so no extra changes needed there.
• CI confirms the fix works: the "Integration tests" workflow run for this PR (which includes Firefox) passed ✅, whereas the original PR chore(deps-dev): bump the minorandpatch group across 1 directory with 3 updates #7007 this is cloned from was failing at this exact step.
• Since the root cause is still not fully understood (as the PR description acknowledges), this reads as a pragmatic workaround rather than a true fix. That's a reasonable tradeoff for unblocking a dependency bump, but if this flake resurfaces elsewhere (there's a history of Firefox flakiness in this suite — Firefox integration test flake: Error: page.waitForURL: net::ERR_SOCKET_NOT_CONNECTED #5555, Firefox e2e flake: Error: locator.waitFor: Target page, context or browser has been closed #5677, Console messages: don't ignore messages in Firefox integration tests #4535), it may be worth investigating whether other .check() calls on similar toggle/checkbox elements (e.g. submission-flow.spec.ts:35-36, search/*.dependent.spec.ts) are also at risk, though that's out of scope for this PR.
• package.json/package-lock.json changes are a standard, consistent lockfile bump — nothing concerning there.

No blocking issues found. This looks safe to merge.

[corneliusroemer]

Thanks for investigating and making a fix PR. Sounds reasonable to me, weird that we suddenly need it but so be it.

[corneliusroemer]

I looked at the trace again and I noticed that when selecting "before" the click location is slightly to the right of the checkbox. Maybe that's why the check goes nowhere - some people on the linked issue suggested the click was in the wrong place.

Doesn't matter though if your workaround works.

[maverbiest]

@corneliusroemer huh that's weird, is that from the failed run https://github.com/loculus-project/loculus/actions/runs/31168223702?pr=7007 ? Because when I looked at that trace the dot was right over the checkbox, also in "before":

I might just go ahead and merge this anyway since it seems to resolve the issue