fix(Provider): guard EIP-6963 announcement on DOM event APIs

[oluwadareab12]

Bug

Provider.create()'s EIP-6963 announcement guarded on window, CustomEvent, and crypto.randomUUID, but not on the DOM event APIs mipd's announceProvider actually calls:

export function announceProvider(detail) {
  const event = new CustomEvent('eip6963:announceProvider', { detail: Object.freeze(detail) })
  window.dispatchEvent(event)
  const handler = () => window.dispatchEvent(event)
  window.addEventListener('eip6963:requestProvider', handler)
  return () => window.removeEventListener('eip6963:requestProvider', handler)
}

In partial window-like runtimes (React Native/Expo, where window is aliased to globalThis and CustomEvent/crypto.randomUUID are polyfilled for unrelated reasons but no DOM event dispatching exists), all three existing guard conditions pass, announceProvider runs, and window.dispatchEvent throws TypeError: undefined is not a function — unhandled at the call site, taking down Provider.create() entirely for any adapter, not just the announcement.

Fix

Extend the guard to also require window.dispatchEvent and window.addEventListener to be functions:

if (
  typeof window !== 'undefined' &&
  typeof window.dispatchEvent === 'function' &&
  typeof window.addEventListener === 'function' &&
  typeof CustomEvent !== 'undefined' &&
  typeof crypto.randomUUID === 'function'
) {

Browser behavior is unchanged. Non-DOM runtimes now silently skip the browser-only EIP-6963 announcement instead of crashing — that seemed like the only reasonable outcome here, since EIP-6963 injected-provider discovery has no meaning outside a DOM environment. Scope is intentionally limited to this guard; nothing else in Provider.create() changed.

Tests

Added src/core/Provider.test.ts coverage (runs in the lib/pure/node project, not the browser suite, since a real browser already has dispatchEvent):

• asserts Provider.create() does not throw when window exists with CustomEvent/crypto.randomUUID but without dispatchEvent/addEventListener
• asserts the happy path still announces (dispatchEvent called) when window has both DOM event APIs

Both tests use an explicit test adapter (rather than relying on Provider.create's default dialog adapter, which separately reads window.location/window.isSecureContext for unrelated reasons) and a randomly-generated rdns per call — Provider.ts dedupes announcements through a module-level announced Set, so a fixed rdns would let one test (or one of vitest's automatic retries of a prior attempt) mask another's guard behavior.

Before the fix (guard reverted locally): the "skips announcement" test fails consistently across all retries with TypeError: window.dispatchEvent is not a function, i.e. reproducing the exact crash from the issue.
After the fix: all 21 tests in the file pass, including both new cases.

Also ran tsc -b --noEmit (clean) and pnpm check (lint+fmt, 0 errors — the 2 warnings printed are pre-existing and in unrelated localnet test files).

Closes #730

---

Saw in the issue thread that @Osraka was considering picking this up — the approach here follows exactly what was outlined there (guard on dispatchEvent/addEventListener, keep browser behavior unchanged, focused regression test). Opened this since no PR had landed yet, but happy to hand off, adjust, or close in favor of theirs if they'd already started work I couldn't see.

[vercel]

@oluwadareab12 is attempting to deploy a commit to the Tempo Team on Vercel.

A member of the Team first needs to authorize it.