|
All checks were successful
Deploy to Production / deploy (push) Successful in 59s
Owner: "wird nicht richtig gestream hab browser daten gelöscht aber kann [nicht]" — clearing the cache didn't help. Three things changed: 1. **Single MP4 source.** Chrome listed the WebM source first because we offered it first; on the owner's setup the VP9 decode appears to stall silently and Chrome does NOT fall back to MP4 — it parks the element at networkState=2/readyState=0 forever. Removing the WebM source forces Chrome onto the MP4 (Main profile / yuv420p / TV-range / faststart, 2.6 MB) which we've already verified plays correctly. 2. **.load() before .play() in togglePlay.** When the original autoplay was blocked before the source ever fetched, some Chrome builds leave the element in a "stuck unloaded" state where subsequent .play() calls inside a user gesture also no-op. Calling .load() first resets the resource-selection algorithm, then .play() fetches and plays. 3. **playFailed escape hatch.** If .play() still rejects even after .load() + user gesture (extension sandbox, hardware decoder failure), surface a small "your browser blocked playback — open the video directly" link to the raw MP4. The visitor isn't trapped staring at a poster. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| particle-hero | ||
| ui | ||
| code-block.tsx | ||
| cookie-banner.tsx | ||
| country-picker.tsx | ||
| docs-page.tsx | ||
| hero-animation.tsx | ||
| hero-step-rotator.tsx | ||
| hero-video.tsx | ||
| input.tsx | ||
| install-snippets.tsx | ||
| json-ld.tsx | ||
| logo.tsx | ||
| marketing-auth-buttons.tsx | ||
| marketing-mobile-menu.tsx | ||
| mobile-action-bar.tsx | ||
| pulse.tsx | ||
| scroll-cue.tsx | ||
| static-code-block.tsx | ||
| status-pill.tsx | ||
| streaming-logs.tsx | ||
| user-menu.tsx | ||