Skip to content

An MP4 file its player cannot read tries Firefox's own player first; the load error says how to watch it on the site - #609

Merged
Nawid3333 merged 2 commits into
mainfrom
feat/direct-before-load-error
Oct 28, 2026
Merged

Nawid3333 merged 2 commits into
mainfrom
feat/direct-before-load-error

Conversation

@Nawid3333

@Nawid3333 Nawid3333 commented Oct 28, 2026 •

Copy link
Copy Markdown
Owner

What changes for the user

  • An MP4 file the MP4 player cannot read (a file mp4box cannot parse, a codec MSE refuses) is played once in Firefox's own player inside FastStream (the existing playDirectly hand-over, at the time it was at), once the next source and a rebuild are no way out, instead of the load error. FastStream's player and its controls stay; nothing of the page comes back by itself.
  • The load error now says how to watch the video in the site's own player, in a page: "Turn FastStream off with its toolbar button to watch it in the site's own player." It is the DRM error's own second sentence, reused in every locale (player_error_turn_off). A player in a tab of its own shows the error alone.

What does not change

  • A refused request (isNetworkFailure: a range or the first fragment that failed to load) still shows the error: Firefox's own player would send the same request, and the page's new link may be on its way (renewSourceLink, Some recommandations #592).
  • A video that has shown a picture is rebuilt first (recoverPlayer), as before; only when its rebuilds are used up does Firefox's own player take over, where the load error showed before.
  • FastStream never steps aside by itself: a version that gave the page its player back was built and dropped unmerged on the owner's word; the toolbar's Off is the user's.

Review

glm's review: the first version tried Firefox's own player only before the first picture, by comparing identifiers, which two episodes at the same URL path share - fixed by dropping that test (the rebuild comes first anyway). Its other findings were checked and are not real: Firefox's own player keeps the page's headers since #607 (the review read an outdated fact), and the stall watchdog fires only after a picture (readyState ≥ 2).

Tests

  • Unit: the MP4 goes to Firefox's own player; a refused range does not; a video that showed a picture is rebuilt first and goes to Firefox's own player once rebuilds are no way out; the error when Firefox's player was tried already; the hint only in a page. Each condition was removed once and its test failed.
  • Local: lint, tsc, 3373 unit tests; e2e ext specs mislabelled-file, fresh-link, header-rules, redirected-source, source-length, same-video-file, framed-player, extension; web specs mp4-without-ranges, mp4-files, mp4-loading, player-recovery, seek-downloads, loader-retry, dash-broken-segment.

🤖 Generated with Claude Code

Nawid3333 and others added 2 commits October 28, 2026 23:22
…the load error says how to watch it on the site

An MP4 file whose player reports an error before anything showed is tried once in Firefox's own
player inside FastStream (playDirectly), which reads files mp4box cannot parse and codecs MSE
refuses. Not for a refused request (isNetworkFailure), which it would send just the same while the
page's new link may be on its way (renewSourceLink), nor once the video has shown a picture.

Only then the load error shows; in a page it now ends with the DRM error's own advice: turn
FastStream off with its toolbar button to watch the video in the site's own player
(player_error_turn_off, that sentence in every locale). FastStream does not step aside by itself.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…picture (glm's review)

"Has this video shown a picture" compared identifiers, and two episodes at the same URL path
share one: after the first played, the second never got Firefox's own player. Now that the
fallback stays inside FastStream, the test is not needed: a video that showed a picture is
rebuilt first (recoverPlayer), and once its rebuilds are used up it plays on in Firefox's own
player at the time it was at, instead of the load error.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@Nawid3333
Nawid3333 merged commit c3bd8f9 into main Oct 28, 2026
23 checks passed
@Nawid3333
Nawid3333 deleted the feat/direct-before-load-error branch October 28, 2026 22:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant