grafana/k6 · error

enabling page domain: %w

Error message

enabling page domain: %w

What it means

FrameSession.initFrameTree (frame_session.go:424) first sends Page.enable before reading the frame tree. If Page.enable fails, frame-session initialization stops with this wrapped error. A failure here means the page target is not accepting commands — closed, crashed, or the session was detached — rather than anything wrong with your script.

Source

Thrown at internal/js/modules/k6/browser/common/frame_session.go:424

	// it seems to pause the exec of any other action on
	// the page. I believe this is an issue in Chromium.
	action := cdppage.HandleJavaScriptDialog(false)
	if event.Type == cdppage.DialogTypeBeforeunload {
		action = cdppage.HandleJavaScriptDialog(true)
	}

	if err := action.Do(cdp.WithExecutor(fs.ctx, fs.session)); err != nil {
		fs.logger.Errorf("FrameSession:onEventJavascriptDialogOpening", "failed to dismiss dialog box: %v", err)
	}
}

func (fs *FrameSession) initFrameTree() error {
	fs.logger.Debugf("NewFrameSession:initFrameTree",
		"sid:%v tid:%v", fs.session.ID(), fs.targetID)

	action := cdppage.Enable()
	if err := action.Do(cdp.WithExecutor(fs.ctx, fs.session)); err != nil {
		return fmt.Errorf("enabling page domain: %w", err)
	}

	var frameTree *cdppage.FrameTree
	var err error

	// Recursively enumerate all existing frames in page to create initial in-memory structures
	// used for access and manipulation from JS.
	action2 := cdppage.GetFrameTree()
	if frameTree, err = action2.Do(cdp.WithExecutor(fs.ctx, fs.session)); err != nil {
		return fmt.Errorf("getting page frame tree: %w", err)
	} else if frameTree == nil {
		// This can happen with very short scripts when we might not have enough
		// time to initialize properly.
		return fmt.Errorf("got a nil page frame tree")
	}

	// Any new frame may have a child frame, not just mainframes.
	fs.handleFrameTree(frameTree, fs.isMainFrame())

View on GitHub (pinned to 93accf6570)

Solutions

  1. Serialize page open/close within a VU so targets are not destroyed while being initialized
  2. Check chromium liveness and memory; restart the browser process between iterations if it degrades
  3. If using a remote endpoint, verify the connection is not dropping (websocket proxy timeouts)
Defensive patterns

Strategy: retry

Try / catch

try {
  const page = browser.newPage();
} catch (e) {
  if (/enabling page domain/i.test(String(e))) {
    // target closed/crashed during init — recreate and retry once
  }
}

Prevention

When it happens

Trigger: Initializing a session for a target that chromium is concurrently destroying (page.close() in another task, browser shutdown), chromium crash, or CDP connection loss. Can also appear for iframe child sessions during page teardown.

Common situations: Scripts with aggressive page lifecycle churn under load, browser process OOM-killed in CI, or a remote browser closing targets behind k6's back.

Related errors


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