grafana/k6 · error

getting node in frame: %w

Error message

getting node in frame: %w

What it means

Thrown by ElementHandle.OwnerFrame() (internal/js/modules/k6/browser/common/element_handle.go:1156) when the CDP call DOM.describeNode, executed with the document element's remote object ID, returns a protocol-level error. The wrapped error comes straight from the Chrome DevTools Protocol session, so the root cause is almost always a lifecycle race (navigation, target close) rather than bad input.

Source

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

	documentHandle, ok := res.(*ElementHandle)
	if !ok {
		return nil, fmt.Errorf("unexpected result type while getting document element: %T", res)
	}
	defer func() {
		if err := documentHandle.Dispose(); err != nil {
			err = fmt.Errorf("disposing document element: %w", err)
			rerr = errors.Join(err, rerr)
		}
	}()

	if documentHandle.remoteObject.ObjectID == "" {
		return nil, err
	}

	var node *cdp.Node
	action := dom.DescribeNode().WithObjectID(documentHandle.remoteObject.ObjectID)
	if node, err = action.Do(cdp.WithExecutor(h.ctx, h.session)); err != nil {
		return nil, fmt.Errorf("getting node in frame: %w", err)
	}
	if node == nil || node.FrameID == "" {
		return nil, fmt.Errorf("no frame found for node: %w", err)
	}

	frame, ok := h.frame.manager.getFrameByID(node.FrameID)
	if !ok {
		return nil, fmt.Errorf("no frame found for id %s", node.FrameID)
	}

	return frame, nil
}

// Press scrolls element into view and presses the given keys.
func (h *ElementHandle) Press(key string, opts *ElementHandlePressOptions) error {
	press := func(apiCtx context.Context, handle *ElementHandle) (any, error) {
		return nil, handle.press(apiCtx, key, KeyboardOptions{})
	}

View on GitHub (pinned to 93accf6570)

Solutions

  1. Re-acquire the element handle after any action that can navigate (click, goto) before calling frame-dependent APIs
  2. Await page.waitForLoadState()/waitForNavigation after navigating actions, then retry the operation
  3. Ensure your script is not closing the page/browser while operations on handles are still running (avoid fire-and-forget promises)
  4. Increase the action/timeout budget if failure correlates with high load or slowMo

Example fix

// before
const el = page.locator('iframe >> button'); // resolves owner frame internally
await page.click('a.next'); // navigation starts
// after
await page.click('a.next');
await page.waitForLoadState('load');
const el = page.locator('iframe >> button'); // re-query after navigation settles
Defensive patterns

Strategy: retry

Validate before calling

// Verify the element is still live before a frame-dependent op
const visible = await el.isVisible();
if (!visible) throw new Error('element gone; re-query before owner-frame op');

Try / catch

try {
  const f = el.ownerFrame(); // or locator with '>>' frame nav
} catch (e) {
  if (/getting node in frame/.test(e.message)) { await page.waitForLoadState(); /* retry once */ }
  else throw e;
}

Prevention

When it happens

Trigger: Calling any API that resolves an element's owner frame (selectors containing frame navigation like 'iframe >> button', setInputFiles internals) while the page navigates, the tab/target is closed, or the browser is shutting down at k6 iteration end; the CDP session or execution context is destroyed mid-call.

Common situations: Holding a stale ElementHandle across a click that triggers navigation; k6 closes the browser while an async browser op is still in flight; heavy load causes the target to crash. Typically intermittent, load-correlated failures.

Related errors


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