fix(player): stop PiP dropping the video and restarting the audio behind it

Watching in a picture-in-picture window would occasionally drop to audio-only,
and the audio would resume from wherever the video had been when PiP was
entered while the picture had carried on past it. Two independent faults, both
needed to produce that.

The position froze (DR-265). VideoPlayer tracks the absolute position in its
own `currentTime` rather than reading `videoElement.currentTime` at the point
of use, because transcoded HLS resets the element to 0 on every segment
rebuild. While playing, that variable had exactly one writer: a
requestAnimationFrame loop. RAF is driven by the document being rendered, and
an Android activity behind a PiP window is paused, so the loop stops while the
element plays on. The `timeupdate` handler that would have covered the gap was
written as a fallback "for when RAF isn't running" and gated itself on
`!isPlaying` -- switching itself off at precisely the moment it was the only
source left. Everything downstream froze with it: the seek bar, the ten-second
progress reports, the position mirrored into Rust, and the handoff. The gate is
now `shouldApplyTimeUpdate` and turns only on things that genuinely own the
position -- an in-flight seek, a seek-bar drag, an element below
HAVE_CURRENT_DATA. Both writers producing the same derived value costs nothing.

The handoff fired at all (DR-266). PiP and the background-audio handoff are
alternatives -- one keeps the picture, the other throws it away -- but
exclusivity was enforced from one side only: arming the toggle suppressed
*auto*-PiP, while the PiP button stayed ungated, so pressing it left both
armed. What then stood between them was `isInPictureInPictureMode`, sampled
once inside MainActivity.onStop(). That sample is not reliable: the keyguard
dismissing the window, the window being stashed, or OEM variance in when
onPictureInPictureModeChanged(false) lands can all leave the activity stopped
with a window still on screen and the flag reading false. Now entering PiP
disarms background audio, both directions go through one BackgroundBehaviour
pair, and the PiP question accepts either witness -- the native sample or the
frontend's latch over jellytau-pip-entered/exited. The latch cannot report a
window that has closed: both events reach the WebView through the same message
queue in dispatch order. The decision itself stays in Rust; the frontend only
supplies a fact it can establish more reliably than the activity can.

Red first, both: the existing behaviour was extracted into pure helpers, the
tests written against the correct behaviour, and both watched to fail before
either was changed.

src/lib/components/player/VideoPlayer.svelte

@@ -80,8 +80,13 @@
     shouldExitBackgroundAudio,
     shouldResumeOnForeground,
     planHandoffReturn,
+    setBackgroundAudioArmed,
+    enteringPictureInPicture,
+    inPictureInPicture,
     type BackgroundAudioState,
+    type BackgroundBehaviour,
   } from "./backgroundAudioHandoff";
+  import { shouldApplyTimeUpdate } from "./timeTracking";
   import { createLogger } from "$lib/utils/logger";
   import { elementSrcFor, loaderForTransport } from "$lib/player/streamTransport";
 
@@ -1350,14 +1355,27 @@
     }
   }
 
-  // Fallback: Update time on timeupdate event (for when RAF isn't running)
+  // Second position source, alongside the RAF loop. It used to exclude itself
+  // whenever the video was playing, on the theory that RAF had it covered --
+  // but RAF only runs while the document is rendered, and an Android activity
+  // behind a PiP window is paused. `currentTime` then froze at the moment PiP
+  // was entered while the element played on, and every consumer of it froze
+  // too: the seek bar, the progress reports, the position mirrored into Rust,
+  // and -- the visible symptom -- the background-audio handoff, which resumed
+  // the audio-only stream back at the PiP-entry position. (DR-265)
   function handleTimeUpdate() {
-    if (videoElement && !isSeeking && !isDraggingSeekBar && !isPlaying) {
-      const newCurrentTime = seekOffset + videoElement.currentTime;
-      if (videoElement.readyState >= 2) {
-        currentTime = newCurrentTime;
-      }
+    if (!videoElement) return;
+    if (
+      !shouldApplyTimeUpdate({
+        isPlaying,
+        isSeeking,
+        isDraggingSeekBar,
+        readyState: videoElement.readyState,
+      })
+    ) {
+      return;
     }
+    currentTime = seekOffset + videoElement.currentTime;
   }
 
   function handleLoadedMetadata() {
@@ -1833,6 +1851,11 @@
   const pipSupported = isPipSupported();
 
   function handlePictureInPicture() {
+    // Pressing PiP is an unambiguous request to keep the picture, so it disarms
+    // the behaviour that throws the picture away. Exclusivity was previously
+    // enforced only from the toggle's side (it suppressed *auto*-PiP), leaving
+    // this button able to arm both at once. (DR-266)
+    applyBackgroundBehaviour(enteringPictureInPicture(backgroundBehaviour()));
     enterPip();
   }
 
@@ -1855,16 +1878,26 @@
   // what we stopped -- never something the user paused themselves.
   let pausedByBackgrounding = false;
 
-  function toggleBackgroundAudio() {
-    backgroundAudioOn = !backgroundAudioOn;
+  /** The pair of background behaviours as they currently stand. */
+  function backgroundBehaviour(): BackgroundBehaviour {
+    return setBackgroundAudioArmed(backgroundAudioOn);
+  }
+
+  /**
+   * Push a background-behaviour pair to both natives, so exactly one is armed.
+   */
+  function applyBackgroundBehaviour(next: BackgroundBehaviour) {
+    backgroundAudioOn = next.backgroundAudioArmed;
     log.debug("Background-audio toggle ->", backgroundAudioOn);
-    // Arm/disarm native background-audio mode AND flip auto-PiP the other way,
-    // so exactly one background behavior is active.
-    const armed = setBackgroundAudioEnabled(backgroundAudioOn);
-    if (!armed) {
+    const armed = setBackgroundAudioEnabled(next.backgroundAudioArmed);
+    if (!armed && next.backgroundAudioArmed) {
       log.warn("Background audio NOT armed natively (no bridge)");
     }
-    setAutoEnterEnabled(!backgroundAudioOn);
+    setAutoEnterEnabled(next.autoPipEnabled);
+  }
+
+  function toggleBackgroundAudio() {
+    applyBackgroundBehaviour(setBackgroundAudioArmed(!backgroundAudioOn));
   }
 
   // App went to background/locked while background-audio is armed: hand off to
@@ -1879,7 +1912,15 @@
     try {
       action = await commands.playerBackgroundAction(
         signal.backgroundAudioArmed,
-        signal.inPictureInPicture,
+        // Not `signal.inPictureInPicture` alone. That is one sample of
+        // `isInPictureInPictureMode`, taken inside onStop(); there are
+        // orderings -- the keyguard dismissing the window, the window being
+        // stashed, OEM variance in when onPictureInPictureModeChanged(false)
+        // lands -- where it reads false with the window still on screen, and
+        // the video the user is watching is handed off to audio. `isInPip` is
+        // a latch over the pip-entered/exited events, which arrive on the same
+        // queue ahead of this one. (DR-266)
+        inPictureInPicture(signal.inPictureInPicture, isInPip),
       );
     } catch (e) {
       // Never leave playback in an undefined state because a decision call

src/lib/components/player/backgroundAudioHandoff.test.ts

@@ -7,6 +7,9 @@ import {
   shouldExitBackgroundAudio,
   shouldResumeOnForeground,
   type BackgroundAudioState,
+  setBackgroundAudioArmed,
+  enteringPictureInPicture,
+  inPictureInPicture,
 } from "./backgroundAudioHandoff";
 
 // TRACES: UR-040 | DR-052 | UT-060
@@ -137,3 +140,69 @@ describe("backgroundAudioHandoff", () => {
     });
   });
 });
+
+/**
+ * TRACES: UT-246 | DR-266
+ */
+describe("background behaviour exclusivity", () => {
+  describe("setBackgroundAudioArmed", () => {
+    it("disables auto-PiP when background audio is armed", () => {
+      expect(setBackgroundAudioArmed(true)).toEqual({
+        backgroundAudioArmed: true,
+        autoPipEnabled: false,
+      });
+    });
+
+    it("restores auto-PiP when background audio is disarmed", () => {
+      expect(setBackgroundAudioArmed(false)).toEqual({
+        backgroundAudioArmed: false,
+        autoPipEnabled: true,
+      });
+    });
+  });
+
+  describe("enteringPictureInPicture", () => {
+    it("disarms background audio when the user opens a PiP window", () => {
+      // THE REPORTED BUG, half one. Exclusivity was enforced in one direction
+      // only: arming the toggle suppressed auto-PiP, but the PiP *button* was
+      // still offered and still worked, leaving both behaviours live at once.
+      // A single stray background signal then handed a video the user was
+      // watching in a PiP window off to audio-only.
+      expect(
+        enteringPictureInPicture({ backgroundAudioArmed: true, autoPipEnabled: false }),
+      ).toEqual({ backgroundAudioArmed: false, autoPipEnabled: true });
+    });
+
+    it("leaves an already-exclusive state alone", () => {
+      const state = { backgroundAudioArmed: false, autoPipEnabled: true };
+      expect(enteringPictureInPicture(state)).toEqual(state);
+    });
+  });
+
+  describe("inPictureInPicture", () => {
+    it("trusts the native flag when the two agree", () => {
+      expect(inPictureInPicture(true, true)).toBe(true);
+      expect(inPictureInPicture(false, false)).toBe(false);
+    });
+
+    it("treats a live PiP window as PiP even when the native flag says otherwise", () => {
+      // THE REPORTED BUG, half two. `isInPictureInPictureMode` is sampled once,
+      // inside onStop(). There are orderings -- the keyguard dismissing the
+      // window, the window being stashed, OEM variance in whether
+      // onPictureInPictureModeChanged(false) lands first -- where the activity
+      // is stopped with a PiP window still on screen and that single boolean
+      // reads false. Backgrounding then means "the app is gone" and the video
+      // the user is watching is handed off to audio.
+      expect(inPictureInPicture(false, true)).toBe(true);
+    });
+
+    it("does not resurrect a window the frontend has already seen close", () => {
+      // jellytau-pip-exited and jellytau-background are both posted to the same
+      // WebView message queue, in that order, so a genuine exit is always known
+      // by the time the background signal is handled. Leaving playback running
+      // here would be the opposite defect: audio continuing after the user
+      // closed the window and left the app.
+      expect(inPictureInPicture(false, false)).toBe(false);
+    });
+  });
+});

src/lib/components/player/backgroundAudioHandoff.ts

@@ -121,3 +121,61 @@ export function planHandoffReturn(opts: {
     shouldPlay: shouldResumeOnForeground(opts.wasPlaying, opts.nativeStateKind),
   };
 }
+
+/**
+ * Which of the two mutually exclusive background behaviours is armed.
+ *
+ * TRACES: UR-040, UR-041 | DR-266 | UT-246
+ *
+ * Backgrounding the app can either shrink the video into a picture-in-picture
+ * window (UR-041) or hand its audio off to the native player and drop the
+ * picture (UR-040). They are alternatives — the first keeps the video on
+ * screen, the second throws it away — so at most one may ever be armed.
+ */
+export interface BackgroundBehaviour {
+  /** The per-player background-audio toggle (UR-040). */
+  backgroundAudioArmed: boolean;
+  /** Whether leaving the app auto-enters PiP (UR-041). */
+  autoPipEnabled: boolean;
+}
+
+/** Arming/disarming the background-audio toggle flips auto-PiP the other way. */
+export function setBackgroundAudioArmed(armed: boolean): BackgroundBehaviour {
+  return { backgroundAudioArmed: armed, autoPipEnabled: !armed };
+}
+
+/**
+ * The user has asked for a PiP window, by pressing the button rather than by
+ * leaving the app.
+ *
+ * Exclusivity used to be enforced from one side only — arming the toggle
+ * suppressed auto-PiP — while the PiP button stayed live and ungated. Pressing
+ * it left both behaviours armed, and the video was then one stray background
+ * signal away from being handed off to audio-only while the user was watching
+ * it in the window. Pressing PiP is an unambiguous request to keep the picture,
+ * so it disarms the behaviour that throws the picture away.
+ */
+export function enteringPictureInPicture(_current: BackgroundBehaviour): BackgroundBehaviour {
+  return setBackgroundAudioArmed(false);
+}
+
+/**
+ * Whether the app is in a picture-in-picture window, for the purpose of
+ * deciding what backgrounding means.
+ *
+ * TRACES: UR-040, UR-041 | DR-266 | UT-246
+ *
+ * @param nativeFlag the Activity's `isInPictureInPictureMode`, sampled inside
+ *   `onStop()`
+ * @param sawPipEntered whether the frontend has seen `jellytau-pip-entered`
+ *   without a matching `jellytau-pip-exited`
+ */
+export function inPictureInPicture(nativeFlag: boolean, sawPipEntered: boolean): boolean {
+  // Either witness is enough. The native flag is a single sample taken inside
+  // onStop(); the frontend's is a latch, set by `jellytau-pip-entered` and
+  // cleared by `jellytau-pip-exited`. Both events reach the WebView through the
+  // same message queue in dispatch order, so a genuine exit is always known
+  // before the background signal that follows it — the latch can report a
+  // window that is still open, never one that has closed.
+  return nativeFlag || sawPipEntered;
+}

src/lib/components/player/timeTracking.test.ts

@@ -0,0 +1,45 @@
+import { describe, it, expect } from "vitest";
+import { shouldApplyTimeUpdate } from "./timeTracking";
+
+/**
+ * TRACES: UT-245 | DR-265
+ */
+describe("shouldApplyTimeUpdate", () => {
+  const base = { isPlaying: false, isSeeking: false, isDraggingSeekBar: false, readyState: 4 };
+
+  it("applies the update while the video is PLAYING", () => {
+    // THE REPORTED BUG. `timeupdate` was the only position source that still
+    // fires once requestAnimationFrame stops -- which is exactly what happens
+    // when the activity is paused behind a picture-in-picture window. Gating it
+    // on `!isPlaying` disabled it precisely when it was the only thing left,
+    // so the component's `currentTime` froze at the moment PiP was entered
+    // while the element played on. The background-audio handoff then resumed
+    // the audio-only stream at that frozen position.
+    expect(shouldApplyTimeUpdate({ ...base, isPlaying: true })).toBe(true);
+  });
+
+  it("still applies the update while paused", () => {
+    // The case it always handled: RAF is stopped, timeupdate carries the seek.
+    expect(shouldApplyTimeUpdate(base)).toBe(true);
+  });
+
+  it("yields to an in-flight seek", () => {
+    // A seek owns the position until it settles; a stale element read landing
+    // mid-seek is what makes a scrubbed video snap back.
+    expect(shouldApplyTimeUpdate({ ...base, isSeeking: true })).toBe(false);
+    expect(shouldApplyTimeUpdate({ ...base, isPlaying: true, isSeeking: true })).toBe(false);
+  });
+
+  it("yields while the user is dragging the seek bar", () => {
+    expect(shouldApplyTimeUpdate({ ...base, isDraggingSeekBar: true })).toBe(false);
+    expect(shouldApplyTimeUpdate({ ...base, isPlaying: true, isDraggingSeekBar: true })).toBe(
+      false,
+    );
+  });
+
+  it("ignores an element with no usable data yet", () => {
+    // readyState < HAVE_CURRENT_DATA reads 0, which would rewind the position.
+    expect(shouldApplyTimeUpdate({ ...base, readyState: 1 })).toBe(false);
+    expect(shouldApplyTimeUpdate({ ...base, isPlaying: true, readyState: 0 })).toBe(false);
+  });
+});

src/lib/components/player/timeTracking.ts

@@ -0,0 +1,45 @@
+/**
+ * Pure helpers for keeping the player's position variable honest.
+ *
+ * TRACES: UR-004, UR-041 | DR-265 | UT-245
+ *
+ * `VideoPlayer.svelte` tracks the absolute playback position in its own
+ * `currentTime` variable rather than reading `videoElement.currentTime` at the
+ * point of use — transcoded HLS resets the element to 0 on every segment
+ * rebuild, so only the component's running total is meaningful. Everything
+ * downstream reads that variable: the seek bar, the progress reports, the
+ * position mirrored into Rust, and the background-audio handoff.
+ *
+ * Which makes "who is allowed to write it" a correctness question, not a
+ * rendering detail — hence a pure module with tests rather than a condition
+ * buried in an event handler.
+ */
+
+export interface TimeUpdateGate {
+  /**
+   * Deliberately does NOT gate the update, and is accepted only to say so.
+   *
+   * `timeupdate` was written as a fallback "for when RAF isn't running" and so
+   * excluded itself whenever `isPlaying` was true. But RAF is driven by the
+   * document being rendered, and an Android activity behind a picture-in-picture
+   * window is paused: the loop stops while the element plays on, and the one
+   * remaining position source had switched itself off. Both writing the same
+   * derived value costs nothing — the element is the authority either way.
+   */
+  isPlaying?: boolean;
+  isSeeking: boolean;
+  isDraggingSeekBar: boolean;
+  readyState: number;
+}
+
+/**
+ * Whether a `timeupdate` event may write the component's position.
+ *
+ * Kept free of Svelte/DOM so the rule is unit-testable without mounting the
+ * player.
+ */
+export function shouldApplyTimeUpdate(opts: TimeUpdateGate): boolean {
+  // An in-flight seek or a drag owns the position until it settles, and an
+  // element with no current data reads 0, which would rewind it.
+  return !opts.isSeeking && !opts.isDraggingSeekBar && opts.readyState >= 2;
+}