[Feature]: Set `this.name` in `TargetClosedError` constructor
Los mantenedores suelen responder en 1 día
@LeonxLJX ya está trabajando en esto.
Desde el 4/9/2026.
- #42549 de @justin-thurman — cerrado sin fusionar
Evaluación
- Dificultad
- 1/5
- Tiempo estimado
- Menos de una hora
- Aptitud para principiantes
- 86/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- testing-qa
Línea de trabajo
Comienza en packages/playwright-core/src/client/errors.ts e inspecciona el constructor de TargetClosedError. Establece el nombre de la instancia como TargetClosedError, sin ampliar el ámbito de las exportaciones públicas. Se considera terminado cuando las instancias creadas por el cliente informen del nombre previsto, mientras que el alcance establecido siga limitado al cambio del constructor.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
🚀 Feature Request
Update: after discussion with @dgozman, we settled on just setting this.name in the constructor and not exporting the error to avoid expanding the export scope. This is sufficient for the primary motivation behind this change. Original proposed scope is below, for reference.
TargetClosedError is currently exported from the internal client/errors.ts module, but it is not part of Playwright’s public package API. Its constructor also does not set this.name, so instances created on the client have name === 'Error' rather than 'TargetClosedError'.
The proposed change is to:
- Export the class as
playwright.errors.TargetClosedError. - Set
this.name = 'TargetClosedError'in its constructor.
I'd be happy to implement this change if it's approved.
Example
try {
await page.click('button');
} catch (error) {
if (error instanceof playwright.errors.TargetClosedError) {
// Handle a page, context, or browser being closed.
}
}
Motivation
Consumers sometimes need to distinguish an expected target closure from other Playwright failures. Without a public class, consumers must inspect error messages, which is brittle, especially in this case, where the message can be overridden.
Playwright already exposes TimeoutError through playwright.errors.TimeoutError and sets this.name for TimeoutErrors. Exposing TargetClosedError through the same API would provide a stable and consistent way to identify this existing error category. Setting its name would also preserve the class identity in logs and serialized/deserialized errors.
My primary use here would be for less ambiguous error handling and reporting. I work on an application that uses Playwright to drive browsers for screenshot capturing, and we try to detect browser crash errors, like this TargetClosedError, vs. other types, but our only option for doing so is to compare against the string 'Target page, context or browser has been closed'. This feels brittle, since that string could change in different Playwright versions, or be overwritten by the error's constructor. Being able to compare against the error class would make this more robust. If increasing the export surface is a concern, setting this.name in the error's constructor would be almost as good without increasing the export surface.
- Lenguaje dominante
- TypeScript
- Estrellas
- 97.4k
- Forks
- 6.6k
- Merge medio
- 18 h 53 min
- PR fusionados (30 d)
- 307
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin 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 microsoft/playwright
-
[Bug]: mouse movement deltas is 0 in mouse events in webkitPosiblemente ocupada @yury-s la tomó hace 1 día. Abiertobrowser-webkit v1.65
microsoft/playwright#43417 · 1 comentario · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
[Bug]: WebKit (WPE) web process aborts at exit in PlatformDisplay::sharedDisplay() since 1.64 (webkit-2370)Posiblemente ocupada @yury-s la tomó hace 1 día. Abiertobrowser-webkit v1.65
microsoft/playwright#43394 · 2 comentarios · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Chromium 149 headless shell crashes in service-worker DevTools resource loading during context teardownPosiblemente ocupada @yury-s la tomó hace 2 días. Abiertobrowser-chromium upstream v1.65
microsoft/playwright#43374 · 2 comentarios · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
[Feature]: Allow `retryStrategy: 'isolated'` in test.describe.configure() for tests requiring zero background workersPosiblemente ocupada @yury-s la tomó hoy. Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 22/100
microsoft/playwright#43351 · 7 comentarios ·
Los mantenedores suelen responder en 1 día
-
[Bug]: Tests whose titles differ only in punctuation share one output directory, and the later test deletes the earlier test's artifactsPosiblemente ocupada @alok-108 la tomó hace 1 día. AbiertoP3-collecting-feedback
Dificultad 4/5 3-5 días Aptitud para principiantes 28/100
microsoft/playwright#43347 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de microsoft/playwright
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
bug category:ai category:devices effort:s
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
LanternOps/breeze#8943 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
-
area:reliability difficulty:easy help wanted points:100 Stellar Wave
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
Divinity-Labs/Lens#341 · 1 comentario ·
Los mantenedores suelen responder en 1 día