grafana/k6 · error

evaluating pointer action: %w

Error message

evaluating pointer action: %w

What it means

All pointer-action checks passed and the actual action closure ran (fn(apiCtx, h, p) — the mouse click/dblclick/hover or touch tap dispatch) but returned an error. This is the CDP input-dispatch stage: Input.dispatchMouseEvent/dispatchTouchEvent failed, the session was closed, or the action closure's own work (e.g. mouse down/up sequence) failed. Distinct from actionability errors: here the browser rejected or could not deliver the input event.

Source

Thrown at internal/js/modules/k6/browser/common/element_handle.go:1775

		// Do a final actionability check to see if element can receive events
		// at mouse position in question
		if !opts.Force {
			if ok, err := h.checkHitTargetAt(apiCtx, *p); !ok {
				return nil, fmt.Errorf("checking hit target: %w", err)
			}
		}
		// Are we only "trialing" the action but not actually performing
		// it (ie. running the actionability checks).
		if opts.Trial {
			return nil, nil //nolint:nilnil
		}

		b := NewBarrier()
		h.frame.manager.addBarrier(b)
		defer h.frame.manager.removeBarrier(b)
		if res, err = fn(apiCtx, h, p); err != nil {
			return nil, fmt.Errorf("evaluating pointer action: %w", err)
		}
		// Do we need to wait for navigation to happen
		if !opts.NoWaitAfter {
			if err = b.Wait(apiCtx); err != nil {
				return nil, fmt.Errorf("waiting for navigation: %w", err)
			}
		}

		return res, nil
	}

	return func(apiCtx context.Context, resultCh chan any, errCh chan error) {
		if res, err := retryPointerAction(apiCtx, pointerFn, opts); err != nil {
			select {
			case <-apiCtx.Done():
			case errCh <- err:
			}
		} else {

View on GitHub (pinned to 93accf6570)

Solutions

1. Check whether the browser/page is still alive (browser logs, K6_BROWSER_LOG=debug) and restart the browser context if crashed
2. Rule out resource exhaustion: raise container memory, close pages/contexts you no longer use
3. Retry the action once after re-acquiring the element — transient session drops often succeed on retry
4. If chromium sandbox/GPU crashes recur, try headless mode or adjust browser launch flags

// ensure the page is alive before dispatching input
if (!page.url()) throw new Error('page is closed'); // simple liveness probe

try {
  el.click();
} catch (e) {
  if (String(e).includes('evaluating pointer action')) {
    // input dispatch failed (session/target drop): one retry after re-query
    page.waitForSelector(sel, { state: 'visible' }).click();
  } else {
    throw e;
  }
}

When it happens

Trigger: Page or browser target closed/crashed between the checks and the dispatch; CDP session dropped (browser killed, connection lost); input dispatch rejected by a defunct target; system under such load that the browser process dies mid-action.

Common situations: Browser OOM in CI containers during heavy pages; closing the page in another concurrent operation while clicking; crashing chromium due to GPU/sandbox issues (--disable-gpu or headless quirks); long soak tests leaking pages until the browser dies.

Related errors

• run if waiting for debugger to attach: %w
• internal error while enabling %T: %w
• mouse down: %w
• mouse up: %w
• mouse move: %w

AI-assisted analysis of grafana/k6@93accf6570 (2026-08-15). Data as JSON: /api/errors/3432a12f0ed23dfd. Report an issue: GitHub.