Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

useAudio/useVideo play lock resets across renders

Abierto Apto para principiantes
  • ¿Algo no está bien?
#2,708 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
75/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
react, typescript
Área
frontend, testing

Línea de trabajo

Comienza en createHTMLMediaHook y en el manejo de lockPlay descrito en la issue; después, sigue la ruta de rerenderizado de los eventos de media. Se considera terminado cuando el bloqueo sobrevive a los rerenderizados hasta que play() se resuelve, con una prueba de regresión específica que cubra el caso de pausa con play pendiente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What is the current behavior?

useAudio and useVideo use a lockPlay local variable inside createHTMLMediaHook to avoid calling pause() while a pending HTMLMediaElement.play() promise is still resolving.

Because lockPlay is a plain local variable, it is recreated on every render. Media events such as play, playing, waiting, pause, durationchange, or timeupdate can call setState, causing a rerender before the original play() promise settles. After that rerender, the lock is reset to false, so a new controls.pause() call can run while the earlier play() promise is still pending.

This weakens the Chromium workaround described in the comment above the lock:

Some browsers return Promise on .play() and may throw errors if one tries to execute another .play() or .pause() while that promise is resolving.

Expected behavior

The play lock should persist across renders until the pending play() promise resolves or rejects.

Using a ref for the lock would preserve the intended behavior without changing the public API.

Why this matters

In video/audio-heavy UIs, components often call controls.play() and controls.pause() in response to store changes, user interactions, or source changes. If a media event causes a rerender while play() is still pending, the current lock can be lost and the hook can issue a conflicting pause().

Possible fix

Change the local variable:

let lockPlay = false;

to a ref-backed value, for example:

const lockPlay = useRef(false);

and read/write lockPlay.current inside the controls.

I can open a PR with a focused regression test if this direction sounds good.

Lenguaje dominante
TypeScript
Estrellas
44k
Forks
3.3k
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de streamich/react-use

Todos los issues de streamich/react-use

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.