bug(ui): table intermittently goes fully black during a SNG while still accepting clicks — player acts blind

Aperta
#838 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Dzeezbtc ci sta già lavorando.

Dal 1/11/2026.

  • #946 di @Dzeezbtc — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript, web-dev
Ambito
frontend, game-dev

Direzione di ricerca

Start by comparing the table rendering and input handling with the fixes for #623 and #41, then inspect the table’s overlay, canvas/WebGL, and WebSocket rendering paths. Reproduce on macOS and gather browser and console details, especially around webglcontextlost. Done means the table keeps the last good view through transient failures, blocks actions whenever the view is unusable, and has a regression test where feasible.

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

Descrizione

bug sit-and-go UI Week 2

Problem

During a live Sit & Go, the screen intermittently goes completely black — the whole table disappears and the player can't see anything about the hand. It comes back after a moment. Reported by a tester 2026-10-19.

Critical detail: the app is still live and accepting input while black. Clicks kept registering during the blackout — when the screen came back, the actions the player had clicked had already gone through. So this is not a freeze or a disconnect; the DOM is alive and hit-testing works. It's a rendering/paint problem — the visuals vanish while the app keeps running underneath.

Environment

  • MacBook (macOS 15.1, Sequoia). Browser still to confirm.
  • This is a useful clue: on MacBooks a GPU/compositor layer loss (Metal-backed accelerated layers, GPU switching between integrated/discrete, or an external-display change) is a classic cause of "the layer paints black but the DOM stays interactive" — which matches exactly what was seen (screen black, clicks still registering). Worth checking webglcontextlost / hardware-acceleration behaviour first on macOS.

Why it matters (severity)

  • This is real money. The player is acting blind — clicking fold/call/raise/bet with no idea what they're clicking or what the board/pot/their cards are. Mis-clicks here cost real USDC. High severity for a live product.

What we know

  • Intermittent, mid-hand, during a SNG.
  • Full black (not a partial glitch).
  • Input still works and actions commit while the screen is black.
  • Transient — it recovers on its own.

Likely areas to investigate

  • GPU/compositor layer loss — if the table/background renders on a GPU-accelerated layer (e.g. the animated background or any canvas/WebGL), a lost or dropped layer paints black while the DOM stays interactive. Check for webglcontextlost events and compositing.
  • A full-screen black overlay that renders but does not block pointer events (so clicks fall through to the live controls underneath) — e.g. a transition/loading/error layer with pointer-events:none or a z-index/opacity bug.
  • WS-driven blanking — closely related to #623 ("never blank the table on one bad frame", now closed) and the screen-flash #41. This may be a regression of #623 or a new variant: a bad/dropped frame blanking the render while the action bus keeps accepting input.

Info to gather (to pin it down)

  • Browser + OS, desktop or mobile.
  • Does a reload fix it, or does it recover on its own? (Reported: recovers on its own.)
  • Console errors / warnings at the moment it goes black (especially webglcontextlost, WS parse errors, React render errors).
  • Does it correlate with a specific moment — new hand, street deal, showdown, an opponent action, a sound?
  • Roughly how often (every few hands? once a session?).

Acceptance criteria

  • AC-1 The table never goes fully black during normal play; a transient render/WS/GPU hiccup degrades gracefully (keep the last good frame, don't paint black).
  • AC-2 If the view is ever unusable, input is blocked too — the player can never act blind (no clicks accepted while the table isn't visible).
  • AC-3 Root cause identified (GPU layer / overlay / WS frame) and covered by a regression test where feasible.

Related: #623 (closed — WS blanking), #41 (closed — SNG screen flash).

Lingua principale
TypeScript
Stelle
2
Fork
5
Merge medio
22h 35m
PR unite (30g)
91

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. 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 block52/ui

Tutte le issue di block52/ui

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.