fix(playwright): replace monolithic waitForCanvas with scoped async helpers

[Copilot]

All 4 WASM BLE API tests timed out because waitForCanvas() required a successful FTMS control-point write before any assertion could run — a condition that frequently never completes on CI against the live GitHub Pages deployment.

Changes

• Split waitForCanvas() into three focused helpers:

  • waitForAppReady() — waits only for #qt-canvas-wrapper to become visible
  • triggerBleScanAndWaitForRequestDevice() — fails fast if window.mt_startBleScan is absent, triggers the scan, then waits for requestDevice to be called (earliest reliable mock signal)
  • waitForFtmsWrite() — waits for writeValueWithResponse to be recorded; called only in the FTMS write test

• Fail fast on missing scan hook — replaces the silent if (typeof window.mt_startBleScan === 'function') no-op with an explicit expect(...).toBeTruthy(), turning a mystery timeout into an actionable failure when the deployed build stops exporting the hook

Before / After

// Before — all 4 tests blocked on FTMS write completing
await waitForCanvas(page); // canvas visible + scan triggered + FTMS write recorded

// After — first 3 tests unblock at requestDevice; only FTMS test waits further
await waitForAppReady(page);
await triggerBleScanAndWaitForRequestDevice(page);
// ...and only in the FTMS test:
await waitForFtmsWrite(page);

[Copilot]

Pull request overview

This PR refactors the Playwright WASM BLE API tests’ synchronization logic to avoid CI timeouts by breaking a monolithic “wait for everything” helper into smaller, scoped async helpers and only waiting for the FTMS write in the one test that needs it.

Changes:

• Replaced waitForCanvas() with waitForAppReady() (canvas visible) plus triggerBleScanAndWaitForRequestDevice() (scan hook + earliest mock signal).
• Added waitForFtmsWrite() and used it only in the FTMS control-point write test.
• Made missing window.mt_startBleScan fail fast instead of silently no-op’ing and timing out.

Comments suppressed due to low confidence (1)

tests/playwright/wasm_btle_api.spec.js:127

• waitForFtmsWrite() resolves on the first recorded writeValueWithResponse, but the comment and the test intent are specifically about the FTMS Control Point write (UUID 0x2AD9, opcode 0x00). To avoid false positives if other writes are introduced (e.g., via js_sendFtmsCommand), tighten the wait predicate to check for a matching FTMS control-point write rather than any write.

  await page.waitForFunction(
    () => {
      const calls = window._btleApiCalls;
      return calls &&
        Array.isArray(calls.writeValueWithResponse) &&
        calls.writeValueWithResponse.length > 0;
    },

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

triggerBleScanAndWaitForRequestDevice() waits for calls.requestDeviceFilters !== null as a proxy for “requestDevice was called”, but requestDeviceFilters is initialized to null and can legitimately remain null if the app ever calls requestDevice() without filters. In that case the helper will hang until timeout rather than failing with a clear assertion. Consider recording an explicit requestDeviceCalled flag in the injected mock (or initializing requestDeviceFilters to undefined and waiting for it to become defined) and wait on that instead.

[MaximumTrainer]

@copilot apply changes based on the comments in this thread

[Copilot]

@copilot apply changes based on the comments in this thread

Done in 51286a2. requestDeviceFilters is now initialized to undefined (instead of null), and the wait condition changed to !== undefined. Since the mock always writes something to requestDeviceFilters when requestDevice is called (either the filters array or null for a filter-less call), the transition from undefined → defined is an unambiguous, hang-free signal that requestDevice was invoked.