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

[GUI] Firefox: route-change view transition deadlocks ~5s (update callback waits on rAF the pending transition holds)

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

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

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

Direzione di ricerca

Inizia da apps/host/src/lib/router.ts ed esamina navigateHash() e la sua callback di aggiornamento di document.startViewTransition(). L’issue segnala un blocco in Firefox causato dall’attesa di due frame di animazione e descrive un fallback con timeout verificato localmente. Conferma il comportamento della transizione della route in Firefox dopo aver applicato la modifica segnalata; il lavoro è terminato quando la navigazione risponde immediatamente senza compromettere la dissolvenza incrociata.

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

Descrizione

Problem: Any route change in the App Host UI (sidebar engine chip, New conversation) makes the page swallow all clicks for ~4-5 s in Firefox, then it recovers by itself. The page is not frozen; a reload is not needed.

Environment: Strata image 0.2.0-beta-nvfp4.3.1 (strata-nvfp4 fork build; apps/host/src/lib/router.ts identical to upstream), Firefox 158.0.1, Fedora Linux, RTX 5090 32 GB, model qwen3.8-flash-next NVFP4, App Host via Caddy on LAN.

Reproduce: Firefox, open the App Host UI, click the engine chip at the sidebar foot (or New conversation). Expected: view crossfades to the target route immediately. Actual: no click anywhere registers for ~4-5 s; CSS animations keep pulsing; the Monitor view's 5 s auto-refresh shows no update until the stall passes; then everything works again. Deterministic on every attempt.

Mechanism: navigateHash() starts a same-document document.startViewTransition() whose update callback flips the hash synchronously, then resolves after two requestAnimationFrame()s:

const transition = document.startViewTransition(
  () => new Promise(done => {
    window.location.hash = next;
    requestAnimationFrame(() => requestAnimationFrame(() => done()));
  }),
);

While a pending view transition waits on its update callback, the browser holds the rendering pipeline - and rAF callbacks are rendering-driven. On Firefox this deadlocks until an internal update-pending guard (observed ~4-5 s) forces it through. That single deadlock explains every symptom: the hash already equals the target, so if (window.location.hash === next) return; early-returns on every further navigation click; non-nav clicks land on a paint-held document; timer-driven DOM updates (Monitor refresh) are deferred; and the main thread is idle throughout, so the DevTools console is instant.

Evidence (collected live during stalls, Firefox DevTools):

  • performance.getEntriesByType('resource') right after recovery: no entry > 300 ms (nothing network-bound).
  • No long tasks anywhere; console evaluation instant (main thread idle).
  • DOM probe (elementFromPoint, computed pointer-events, [inert]) identical frozen vs. healthy - no input interceptor.
  • Stall is consistent 4-5 s on every click; setting document.documentElement.dataset.motion = 'reduced' (which takes the existing non-morph path in navigateHash) removes it immediately.
  • Chromium never reproduces it, and hidden/background tabs skip view transitions entirely, so headless UI tests structurally cannot catch this.

Note: isWebKitGtk() exists because WebKitGTK crashes on startViewTransition - same API, same engine-quirk category, different failure mode. Firefox's implementation doesn't crash; it starves the callback.

Proposed fix (either suffices):

  1. Race the frame wait against a deadline, one line:
() => new Promise(done => {
  window.location.hash = next;
  requestAnimationFrame(() => requestAnimationFrame(done));
  setTimeout(done, 250); // safety rail: rAF can be held by the transition itself
})

(Double resolution is a no-op; unaffected engines behave exactly as before. We have shipped this local edit over the built bundle and the stall is gone in Firefox 158.)

  1. Or gate Firefox the way WebKitGTK is gated, though that drops the crossfade for all Firefox users.

Reproduction status: reproduced locally (two users, every attempt, workaround and fix both verified).

Lingua principale
C++
Stelle
11.6k
Fork
1k
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 Niko1221/Strata

Tutte le issue di Niko1221/Strata

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.