Sure thing - clanker summary below

Symptom

In extension mode on Chromium, Playwriter briefly connects and may
successfully attach to a tab, but then the extension deactivates and enters a repeated
reconnect/disconnect loop.

Observed user-facing failure:

extension activates
sometimes attaches to the tab
then deactivates again
Playwriter commands fail with:
- No Playwright pages are available. Enable Playwriter on a tab...

Evidence from logs

Relay logs repeatedly show:

Replacing extension connection for browser:Chromium
Extension disconnected: code=4001 reason=Extension Replaced
Rebinding clients ... (stableKey: browser:Chromium)

At least once, the extension fully attached before failing:

Starting connection to tab 326871596
Debugger attached successfully to tab: 326871596
Target.attachedToTarget ...
Successfully connected to tab 326871596

Attached tab example:

tab id: 326871596
URL: https://github.com/remorses/playwriter/issues/74

So this is not only a “no tab enabled” problem — the extension can attach
successfully first, then loses the bridge.

Repository inspected

Cloned repo:

https://github.com/remorses/playwriter
local path: /Users/am/Coding/tmp/playwriter

Key files:

playwriter/src/cdp-relay.ts
extension/src/background.ts
playwriter/src/relay-state.ts

Likely root cause

This looks like a handoff / reconnect race caused by a combination of:

stable extension identity is too coarse
relay forcibly replaces older same-key connections
extension reconnect loop thinks the slot is free too early
Chromium often falls back to the coarse key browser:Chromium

Relevant code paths

1) Stable key generation is too broad

File:

playwriter/src/cdp-relay.ts

Code:

const buildStableExtensionKey = (info, connectionId) => {
  if (info.id) return `profile:${info.id}`
  if (info.email) return `email:${info.email}`
  if (info.browser) return `browser:${info.browser}`
  return `connection:${connectionId}`
}

### Why this matters

If Chromium does not provide id or email, all extension connections collapse to:

- browser:Chromium

That means multiple distinct websocket connections from Chromium are treated as the same
extension identity.


### 2) Relay force-replaces existing connection with same stable key

File:
- playwriter/src/cdp-relay.ts

Code:

```ts
const existingExt = relayState.findExtensionByStableKey(store.getState(), stableKey)
if (existingExt && existingExt.id !== connectionId) {
  existingExt.ws.close(4001, 'Extension Replaced')
}

Why this matters

Any new Chromium extension websocket using stable key browser:Chromium will close the
previous one with:

close code: 4001
reason: Extension Replaced

This exactly matches the logs.

3) Extension treats 4001 as “another extension took over” and enters polling mode

File:

extension/src/background.ts

Code:

  const isExtensionReplaced = reason === 'Extension Replaced' || code === 4001
  ...
  store.setState({
    tabs: new Map(),
    connectionState: 'extension-replaced',
    errorText: 'Another Playwriter extension took over the connection',
  })

Why this matters

After replacement, the old extension clears tab state and starts polling to reclaim the
slot.

4) Reconnect logic may declare the slot “free” too early

File:

extension/src/background.ts

Code:

  const response = await fetch(`http://${RELAY_HOST}:${RELAY_PORT}/extension/status`)
  const data = await response.json()
  const slotAvailable = !data.connected || data.activeTargets === 0
  if (slotAvailable) {
    store.setState({ connectionState: 'idle', errorText: undefined })
  }

Why this matters

The old extension decides it can reconnect if either:

no extension is connected, or
the current extension has activeTargets === 0

That second condition is risky during handoff.

5) Relay status endpoint may report activeTargets = 0 during a legitimate

replacement handoff

File:

playwriter/src/cdp-relay.ts

Code:

  const defaultExtension = getExtensionConnection(null, { allowFallback: true })
  const connected = store.getState().extensions.size > 0
  const activeTargets = defaultExtension?.connectedTargets.size || 0

Why this matters

A newly connected replacement extension may exist but not yet have reattached targets,
so status can transiently be:

connected = true
activeTargets = 0

The previously replaced extension sees that and decides:

“slot is free”
reconnect now

That reconnect then replaces the new one again.

This can create an infinite self-replacement loop.

Working theory

The loop is likely caused by:

Chromium connections sharing the broad stable key browser:Chromium
relay forcibly replacing any existing connection with the same stable key
replaced extension polling /extension/status
/extension/status transiently reporting activeTargets === 0
old extension reconnecting too soon and replacing the new extension again

This matches the observed behavior:

attach succeeds briefly
then repeated 4001 Extension Replaced
then no page remains usable

Why Chromium may be especially affected

If chrome.identity.getProfileUserInfo() does not provide a unique id or email, the
connection identity degrades to:

browser:Chromium

That is not unique per:

profile
extension worker instance
browser window/session

So unrelated reconnects within Chromium can all collide on the same stable key.

Best concise diagnosis

Probable bug: extension-mode reconnect race caused by coarse stable keying
(browser:Chromium) plus early reclaim logic based on activeTargets === 0.

Frequent disconnects #74

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions