Desktop browser tabs stay on the empty page after one tab detaches during server setup
Los mantenedores suelen responder en 1 día
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Estancado
- Stack tecnológico
- playwright, typescript
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- TypeScript
- Estrellas
- 24.8k
- Forks
- 6.4k
- Merge medio
- 10 h 56 min
- PR fusionados (30 d)
- 226
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de pingdotgg/t3code
-
[Bug]: request_secret file delivery has no trailing newline, and the tool text does not say soPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 69/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
[Bug]: Changing the sidebar project filter collapses an expanded Settled shelf back to 10 threadsAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
pingdotgg/t3code#34291 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
Los mantenedores suelen responder en 1 día
-
via-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
Todos los issues de pingdotgg/t3code
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
lingdojo/kana-dojo#33947 · 1 comentario · 5 reacciones ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
paperclipai/paperclip#20942 ·
Los mantenedores suelen responder en 1 día
-
area: documentation good first issue package: rule-data status: accepting prs
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
status: needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
mastra-ai/mastra#30109 · 2 comentarios ·
Los mantenedores suelen responder en 1 día