Clicking a video from history (or any cached watch page) restarted it from 0
instead of resuming, and history bars showed stale positions. Four shared-path
bugs, all engine-agnostic:
- The resume position was computed but never applied: Shaka's load(uri, startTime)
doesn't perform the initial seek for lazily-fetched segment indexes, so playback
began at 0. Apply the resume explicitly with a runtime seek once load() resolves.
- initialSeekComplete (gates progress saving until the resume seek lands) was never
reset per-load. On a reactivated player it stayed true from the previous play, so
a timeupdate at currentTime=0 during rebuild churn overwrote the saved position
before the resume read ran. Reset it at the start of loadVideo.
- Leaving a watch page (destroy) empties the media element -> currentTime snaps to
0 and a stray timeupdate fires while initialSeekComplete is still true, clobbering
the saved position. Gate the save on destroying as well.
- HistoryPage: re-read watch_history in onActivated so progress bars reflect the
current saved position instead of a stale first-mount snapshot. Kept off onMounted
to avoid double-loading (both fire on first keep-alive mount).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Replace shaka-player#4775 link (closed) with TeamPiped/Piped#4238 as the
ongoing tracker.
- Add measured rough per-call cost: Chromium ~0.1 ms vs Firefox ~20 ms.
- Call out explicitly that this is a hack: forcing smooth/powerEfficient to
true throws away signals Shaka would otherwise see. If anything in the
player chain reads those fields (preferredDecodingAttributes is set, a
downstream consumer ranks variants on power efficiency, or a Shaka
upgrade changes filtering), Shaka will pick streams the device cannot
decode in real time — frame drops, software-decode CPU spikes, battery
drain. Today (Shaka 5.1, Piped default config) the fields are not read
and the shim is harmless; revisit on every Shaka upgrade.
Refs: https://github.com/TeamPiped/Piped/issues/4238
VideoPlayer calls videoEl.focus() on every seek-bar mouseup (existing
upstream code, so hotkeys-js continues receiving keys). Firefox/Gecko
draws the system :focus outline whenever a <video> element is focused;
Chromium uses :focus-visible heuristics on media elements and doesn't
render it for click-driven focus, which is why this is Gecko-only.
Add a targeted CSS rule outside the Tailwind @layer so it wins the
cascade against any layered author or vendor rule, and !important to
override the UA focus ring.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Firefox's navigator.mediaCapabilities.decodingInfo costs ~14 ms per call
(out-of-process RDD decoder probe). Shaka Player calls it once per Variant
in the DASH manifest while filtering supported variants, and YouTube
manifests routinely have 1000+ variants, so player initialization stalls
15-20 s on Gecko-based browsers before the first SourceBuffer is added.
Wrap decodingInfo to delegate "supported" checks to
MediaSource.isTypeSupported (sub-ms on Firefox) with a per-MIME cache.
DRM probes and non-media-source queries fall through to native.
Wrapper is gated to Gecko UAs so Chromium and Safari are unaffected.
Refs: https://github.com/shaka-project/shaka-player/issues/4775
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The chevron button to toggle theater mode was invisible on the light
theme because it inherited the dark text color while being positioned
against the video's dark background.
Adding text-white ensures the button is always visible regardless of
the selected theme, since it always appears against the dark video
background.
Fixes#4072
Signed-off-by: pierreeurope <pierre.europe@pm.me>
Removes the Safari-specific check that was preventing selectAudioLanguage()
from being called. This was causing:
1. Videos defaulting to first audio track instead of preferred language
2. Language menu not appearing in player overflow menu
Fixes#4090
