Desktop browser tabs stay on the empty page after one tab detaches during server setup

オープン
#34,251 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@yaacovcorcos がすでに取り組んでいます。

2026年11月11日 から。

  • #34252 @yaacovcorcos による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
playwright, typescript
領域
backend, desktop

調査の方向性

Start with ServerBrowser.setUpTab and the DesktopBrowserChannel detached handler in apps/server, then trace the relay WebSocket endpoint’s queue-to-socket writer and the ensureTab consumers. Reproduce using the temporary delay after connectDesktop and the listed detach steps. Done means a detached tab cannot leave setup waiting indefinitely or block later desktop tabs; issue #34252 already has an open linked pull request.

索引モデルが issue の本文から書いたものです。

説明

Area: apps/server (preview: ServerBrowser, DesktopBrowserChannel)

Steps to reproduce

The window is a few hundred milliseconds wide, so it needs the desktop to detach a tab while the
server is setting it up. To make it deterministic, add a temporary
await new Promise((r) => setTimeout(r, 2500)) right after connectDesktop in
ServerBrowser.setUpTab, then in the desktop app:

  1. Open a browser tab in a thread.
  2. Within those 2.5 s, make the desktop detach the tab (for example, its webview moves to another
    app window, or the tab's webview is recreated).
  3. Open another browser tab and enter an address or a search.

Expected behavior

The new tab shows the page it loaded.

Actual behavior

The webview loads the page, but the panel keeps showing the empty page over it (the spinner
shows, then nothing). Every later user-opened desktop tab does the same until the app restarts.
Agent-opened tabs keep working.

Cause

When the desktop detaches a tab, DesktopBrowserChannel's detached handler shuts that tab's
inbound queue, but the relay WebSocket stays open: the endpoint's handler forks the queue→socket
writer and then loops on reader.pull forever. Playwright never sees a disconnect, so the next
CDP call in setUpTab after the connect (newCDPSession, the PDF navigation setup, or
Page.enable) never answers. ensureTab's promise for that tab never settles. The
desktopChannel.attached and manager.events consumers await ensureTab inside
Stream.runForEach, so every later attach or opened event waits behind it: no later desktop tab
is set up, its snapshot stays Idle, and the client renders the empty state. Agent tabs are set
up through findTab, outside those consumers.

Impact

High for desktop browser users: search, typed addresses and recent sites stop working in every
new tab until restart, with no error.

Version or commit

Code path unchanged on main at 5bb5d53312. Observed in a downstream desktop build based on T3 at
44ebb2fe57.

Environment

macOS 26, desktop app, two app windows open.

Logs

Inspecting the running server's heap: pendingTabs held one tab whose promise never settled while
inbound for that key was Done; every tab attached afterwards was in attachedTabs but in
neither tabs nor pendingTabs, with snapshots Idle/Loading while the desktop webview showed
the loaded page.

Workaround

Restart the app.

主要言語
TypeScript
スター
24.8k
フォーク
6.4k
平均マージ
10時間 56分
マージ済み PR(30日)
226

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

pingdotgg/t3code のほかの issue

pingdotgg/t3code の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。