Desktop browser tabs stay on the empty page after one tab detaches during server setup
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Ferma
- Stack tecnologico
- playwright, typescript
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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:
- Open a browser tab in a thread.
- 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). - 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.
- Lingua principale
- TypeScript
- Stelle
- 24.8k
- Fork
- 6.4k
- Merge medio
- 10h 56m
- PR unite (30g)
- 226
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di pingdotgg/t3code
-
[Bug]: request_secret file delivery has no trailing newline, and the tool text does not say soForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 69/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
[Bug]: Changing the sidebar project filter collapses an expanded Settled shelf back to 10 threadsAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
pingdotgg/t3code#34291 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 1 giorno
-
via-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di pingdotgg/t3code
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
lingdojo/kana-dojo#33947 · 1 commento · 5 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
paperclipai/paperclip#20942 ·
I maintainer di solito rispondono entro 1 giorno
-
area: documentation good first issue package: rule-data status: accepting prs
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
status: needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
mastra-ai/mastra#30109 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno