Skip to content

fix(browser): make waitFor options explicit and race-safe #110

Description

@MagMueller

Problem

Session.waitFor currently has the positional signature waitFor(method, predicate?, timeoutMs?). The natural call shape waitFor(method, { timeoutMs: 15000 }) treats the options object as a predicate. When an event arrives, that object is called as a function; the event-dispatch loop swallows the resulting listener exception, so the event is lost and the default timeout eventually fires.

The browser-execute skill also demonstrates Page.navigate() followed by waitFor("Page.loadEventFired"). A fast load event can arrive before the listener is registered.

Minimal reproduction

const waiting = session.waitFor(
  "Page.loadEventFired",
  { timeoutMs: 20 },
)

// Deliver Page.loadEventFired here. The event is discarded and `waiting` times out.

The same missed-event behavior can be reproduced by delivering the event immediately after Page.navigate() resolves but before calling waitFor().

Proposed fix

  • Support and document an options form such as waitFor(method, { predicate?, timeoutMs? }), while retaining the existing positional form if compatibility requires it.
  • Validate argument types immediately instead of treating arbitrary truthy values as predicates.
  • If a predicate throws, unsubscribe and reject that waiter; do not swallow the exception and continue waiting.
  • Update the navigation example to register the waiter before invoking Page.navigate().
  • Add deterministic unit tests for the options form, custom timeout, predicate failure, and an event emitted during navigation.

This issue intentionally describes the general API behavior only.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions