[Nawid3333]

On an HLS or DASH page, the player could open a single piece of the stream instead of the stream. That piece never plays. Now a piece whose length is still being read counts as a piece, like the others, and the stream plays.

This changes which stream plays. As you decided tonight, it merges on green CI, and you test the release in your own Firefox later.

What went wrong

Tonight's live test (real streams, main at 6852e43) failed once and passed on the retry. The case was "HLS in a cross-origin iframe that may go fullscreen", with Shaka's 60-second angel-one demo. The player opened a-eng-0128k-aac-2c-s15.mp4, one audio segment and the last of 38 sources, and it never became playable (readyState 0).

• Since feat(detection): find manifests by their Content-Type, and play the longest stream #50 the player plays the longest of a page's streams. fix(detection): a stream's .mp4 pieces no longer outrank its manifest #61 made a stream's .mp4 segments count as pieces, which rank below everything.
• Before it picks, the background waits up to 2.5 s for the lengths to be read. The page keeps fetching segments meanwhile, and the newest one's read was still out when the wait ended.
• A length not read yet ranks as unknown, which counts as ten minutes. That is more than the 60-second manifest, and as the newest source, s15 played.
• Once read, s15 is a piece like the others. It won only because its read had not finished.

The fix

• A file (an MP4 or a direct file) whose length is not read yet, or could not be read, counts as a piece when another of the page's sources was read as a piece and has the same URL but for its numbers: seg-14.mp4 and seg-15.mp4. The query counts too: numbers in it may differ, letters may not. The fragment is ignored.
• A manifest never counts as a piece this way.
• A length that was read always stays as read.
• Both picks use it: the player's (sendSources) and the mpv hand-off's (newestOfLongest).
• Files: chrome/background/StreamLengths.mjs (lengthsOf, shape) and chrome/background/background.mjs (the two call sites).

Tests

• Unit, tests/unit/StreamLengths.test.mjs: one new case with 11 sources:

  • a piece not read yet;
  • one whose read failed;
  • a direct file;
  • a read length that stays;
  • another name;
  • other letters in the query;
  • one address with files and a manifest.

  A second check makes sure nothing is guessed when no piece was read.

• e2e, tests/e2e/ext-specs/source-length.e2e.mjs: one new case. A 9-second HLS page fetches its pieces, and the background's read of the third piece is answered only after 5 s.

  • Without the fix, it failed on both attempts, playing seg-002.mp4: the same symptom as the live test.
  • With the fix, the whole spec passes, 5 of 5.

• Local: lint, typecheck, 623 unit tests and the build. CI runs the full e2e suites.

• Review: GLM 5.3 reviewed the fix. It confirmed that:

  • the live case is fixed;
  • only unread or unreadable files change, and only downward;
  • a manifest can neither mark nor become a piece.

  Its doc findings are fixed in the second commit.

Known limits

• Made worse, rarely: some sites fetch everything by number through one address (/get?id=123). On such a site, a film whose read has not finished counts as a piece once another file there was read as one. A short ad's manifest would then play instead. Before, the unread film counted as ten minutes and won. No rule on the URL can tell this film from a piece. The film stays in the sources menu.
• Not fixed, no change: pieces whose query differs in letters, such as per-segment signatures (?Signature=...). They still count as unknown, as before.
• Not fixed, no change: a page where no piece's read finished within 2.5 s.

🤖 Generated with Claude Code