Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

useAudio/useVideo play lock resets across renders

Aperta Adatta ai principianti
  • Qualcosa non va?
#2,708 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
75/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
react, typescript
Ambito
frontend, testing

Direzione di ricerca

Inizia da createHTMLMediaHook e dalla gestione di lockPlay descritta nell’issue, quindi segui il percorso di rerendering degli eventi media. Il lavoro è completo quando il blocco sopravvive ai rerendering fino alla risoluzione di play(), con un test di regressione mirato che copra il caso di pausa mentre play() è in sospeso.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
44k
Fork
3.3k
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di streamich/react-use

Tutte le issue di streamich/react-use

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.