[Feature]: Expose Chromium foreground-tab and tab-strip metadata (Chrome 150+)

[pirate]

Current package version

playwright 1.61.1

🚀 Feature Request

Chrome 150 now exposes the real browser-UI state of tabs through CDP. I would like Playwright to expose a read-only way to answer questions such as:

• Which tab is active in each Chrome window?
• Where is a tab in the tab strip?
• Is it pinned or grouped?
• Which Chrome window contains it?
• Which Playwright Page or pages belong to that tab?

This is especially useful when Playwright is connected to a user-owned browser, or when a human and automation coexist in the same headed browser. It is also useful for MCP/browser-agent integrations, where assuming that the newest page is the foreground page is unreliable.

This request is specifically about reading the real Chrome tab-strip state. It is separate from:

1. activating a tab with page.bringToFront() / Target.activateTarget;
2. raising or focusing the native Chrome application/window at the OS level;
3. emulating DOM focus with Emulation.setFocusEmulationEnabled; and
4. disabling renderer throttling for background or occluded pages.

Why this was not possible before

Historically, CDP only exposed page/renderer targets. It did not expose the browser UI metadata needed to know which tab a human was actually viewing.

In particular:

• The order returned by Target.getTargets is not tab-strip order or focus history.
• The most recently created page is not necessarily the active tab.
• document.hasFocus(), document.visibilityState, focus/blur listeners, and injected scripts are renderer-level signals rather than authoritative tab-strip state.
• Calling page.bringToFront() mutates state, may steal user focus, and cannot be used as a read operation.
• A browser extension can query chrome.tabs, but requiring an extension is not a general Playwright solution.

Playwright also intentionally makes Chromium pages behave as focused by sending:

Emulation.setFocusEmulationEnabled({ enabled: true })

That behavior was introduced to make focus/blur events and automation deterministic and to avoid the timer, RAF, rendering, and screenshot problems associated with background pages. As a result, page-JavaScript checks cannot reliably identify the real foreground tab in a Playwright-controlled browser.

Several previous issues therefore correctly concluded that Playwright could not answer this question at the time.

What changed in Chrome 150

Chrome 150, now in the Stable channel, adds an embedderData object to Target.TargetInfo for targets of type "tab".

A client can now request tab targets directly:

const { targetInfos } = await cdp.send("Target.getTargets", {
  filter: [
    { type: "tab", exclude: false },
    { exclude: true },
  ],
});

Each Chrome tab target can include:

type ChromeTabEmbedderData = {
  tabStripIndex: number;
  tabActive: boolean;
  tabPinned: boolean;
  tabGroupId?: string;
};

The existing browserContextId identifies the browser context, and Browser.getWindowForTarget can return the containing Chrome window ID.

Playwright current Chromium protocol types already include the new TargetInfo.embedderData field as a generic object, so the protocol definition has reached the repository. The remaining work is to consume the tab targets, associate them with Playwright pages, and expose an appropriate public API.

The Chromium implementation and background are documented here:

• Chromium CL: https://chromium-review.googlesource.com/c/chromium/src/+/7787097
• Chromium issue: https://issues.chromium.org/issues/497896141
• Explanation and example: https://www.browserbase.com/blog/cdp-foreground-tab-tracking
• Chrome 150 Stable announcement: https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html

A few protocol details:

• This metadata belongs to "tab" targets, not "page" targets, a tab can contain multiple page targets because of Chromium's multi-page architecture, so implementations should not assume a one-tab-to-one-page relationship.
• Target.autoAttachRelated can be used to discover the page targets related to a tab target.
• The result is currently pull-based. Chrome does not emit new Target.targetInfoChanged events when only this tab metadata changes.
• tabActive means selected in its containing Chrome window. It does not by itself say that the native Chrome window is the OS foreground window.

Possible Playwright API shapes

I do not have a strong preference about the exact public shape. A few possibilities:

1. Minimal page query

await page.isActive(): Promise<boolean | null>

null could mean unavailable on this browser/version or that the page cannot be mapped to a tab.

2. Page tab snapshot

type TabInfo = {
  active: boolean;
  index: number;
  pinned: boolean;
  groupId: string | null;
  windowId?: string;
};

await page.tabInfo(): Promise<TabInfo | null>

Making this asynchronous communicates that it is a current snapshot rather than a live handle.

3. Browser-context tab inventory

const tabs = await context.tabs();

for (const tab of tabs) {
  console.log(
    tab.active,
    tab.index,
    tab.pinned,
    tab.groupId,
    tab.windowId,
    tab.pages(),
  );
}

This may fit the underlying model best because a Chrome tab is a browser-UI container and can own multiple page targets.

4. Chromium-specific API first

If a cross-browser Playwright API is premature, this could initially be exposed as a Chromium-specific/experimental API while preserving a shape that Firefox and WebKit could implement later if equivalent browser-level data becomes available.

For Chrome versions before 150 and for embedders that do not provide the metadata, the API could return null, omit tab metadata, or throw a clearly documented unsupported-operation error.

Interaction with Playwright focus emulation

Reading tabActive does not require Playwright to remove its existing focus emulation.

A low-risk first implementation could:

• preserve Emulation.setFocusEmulationEnabled({enabled: true}) by default;
• expose the real tab-strip state independently through tabInfo(), isActive(), or context.tabs();
• avoid changing document.hasFocus(), document.visibilityState, timer throttling, or existing test behavior; and
• keep page.bringToFront() as an explicit mutating operation.

Separately, Playwright could eventually offer an opt-in such as a context option or page method to disable focus emulation for tests that specifically need real blur/visibility/background behavior. That would solve a different part of the older requests and would need careful handling because it reintroduces browser throttling and rendering differences.

In other words, exposing real tab metadata can be implemented without changing Playwright's deterministic focus defaults. Real focus/background emulation can remain a separate design decision.

Related issues and PRs

Reading the active/user-selected tab

• [Feature]: Get the current actived page. #31890 — request for the current active page
• [Question]: Is there a way to check which page/tab is currently active/visible on a given context ? #8090 — request to detect the page/tab manually selected by a user
• [Feature] Allow inactive tabs to be backgrounded #3570 — inactive/background tabs, including a proposed page.isActive()
• [BUG] click button which jump to new tab, the page visibilitychange event is not triggered. #24130 — tab changes do not produce the expected visibilitychange

Background, visibility, and focus behavior

• [Feature] Toggle page visibility that affects document.visibilityState #2286 — toggling document.visibilityState
• [Question] How to deactivate page? #26343 — deactivating/backgrounding a page; folded into [Feature] Allow inactive tabs to be backgrounded #3570
• [BUG] - Weird behaviour in window blur event #11645 — blur and document.hasFocus() behavior under forced focus emulation
• [BUG] Missing blur and focus events #979 and fix(chromium): emit focus events in headful #982 — missing focus/blur events and the Chromium focus-emulation implementation
• [internal] Screenshots hang on Focus emulated Page with new headless #33330 — screenshots hanging on a focus-emulated page
• [Question] Screenshot timeouts on background tab when using Chrome headful #16307 — background-tab screenshot timeouts despite the backgrounding/throttling flags
• [BUG] Screenshot: Reduce flicker in headful mode. #2576 — screenshot foregrounding/flicker and Chromium not producing background frames

Activation and native-window focus

• How to make page bring to front #2603 and feat(bringToFront): enable on all browsers #3052 — page.bringToFront()
• [Question] How to disable bringing page to front during launching. #4822 — creating pages/windows steals the human user's OS focus
• [Feature]: bringToFront() for Context #36082 — tab foregrounding versus foregrounding the containing native window
• feat(chromium): add createPagesInBackground launch option to avoid stealing focus #41282 — proposed createPagesInBackground option, closed unmerged
• [Feature]: Allow Chrome to launch in the background during headful mode #41306 — current follow-up for launching/creating Chromium pages without stealing OS focus

The new Chrome metadata directly addresses the read/query side of #31890, #8090, and part of #3570. It does not by itself solve background-state emulation or OS-level focus stealing, but it lets Playwright stop relying on guesses or page-JavaScript heuristics when it needs to know the real foreground tab.

Motivation

Playwright is increasingly used beyond QA in hybrid environments where automation, browser agents, MCP clients, and humans share a headed browser. In those environments, reliable foreground-tab tracking is essential to avoid working on the wrong page. This is especially important for https://github.com/microsoft/Webwright and https://github.com/microsoft/playwright-mcp where agent focus and browser tab focus often need to be kept in sync so the user can follow what an agent is doing.

[yury-s]

Thanks for the detailed writeup. We prototyped this (#42355) and discussed it with the team, but decided not to proceed: the API comes with too many caveats for the value it delivers, and we couldn't find a compelling use case. Closing for now — if you have a concrete scenario this would unblock, please file a new issue and we'll revisit.

[pirate]

we couldn't find a compelling use case

Are you not using Playwright for human-in-the-loop automation much within Microsoft? Surely the people that work on microsoft/Webwright and microsoft/playwright-mcp have run into this issue?

How else are you supposed to tell what tab the human has foregrounded while automating a workflow at the same time? Or even within an automated workflow, what if a tab self-closes with window.close(), how do you detect which next tab gets focus without hacks like document.onfocus tracking?

(You can see how much of a struggle that is historically from all the issues I linked under Related issues and PRs.)