Repository navigation
A late failure of the last source's player stays its own; one list says who may message the background - #608
Merged
Conversation
…ys who may message the background setSource counts the next source at once, and the last source's player stays the player until resetPlayer tears it down. What it reported in between was taken for the new source's: its hand-over to Firefox's own player played the old URL over the source the user had just picked, its error and NEED_KEY showed the load error over it, and a refused link of the old source was asked for anew and rebuilt over it. tryNextSource and recoverPlayer checked this already; every failure route does now (FastStreamClient.isCurrentAttempt; renewSourceLink also after the background's answer). The background's runtime.onMessage answered 33 message types, and some checked their sender where they were answered while others did not: LOAD_OPTIONS, MPV_TEST, CLEAR_SOURCES and REQUEST_PLAYLIST_NAVIGATION, which only the options page or the player send, did what any content script asked. MessageSenders now says for every type whether FastStream's own pages only or its content scripts too may send it, read before any handler, in place of the five inline checks. backgroundMessages.test.mjs keeps it complete: every answered type listed, none a content script sends marked own-pages-only. The test harness sends an own-pages message from the player page unless a test names another sender. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two small fixes the refactor review of 1.3.82.160 found (no refactor of working code).
1. A failure of the last source's player no longer touches the next source
setSourcecounts the next source at once, but the last source's player staysthis.playeruntilresetPlayertears it down. What it reported in between was taken for the new source's:PLAY_DIRECTLY) played the old URL over the source the user had just picked;ERROR/NEED_KEYshowed the load error over the source on its way in;renewSourceLink, also when the answer came after the next source was asked for).tryNextSourceandrecoverPlayeralready checkedfallbacks.request === sourceRequests; every failure route does now (FastStreamClient.isCurrentAttempt, plus the check inrenewSourceLinkbefore asking and after the answer).2. One list says who may send the background each message
runtime.onMessageanswers 33 message types. Five checkedfromOwnPage(sender)where they were answered; others did not, though only FastStream's own pages send them:LOAD_OPTIONS,MPV_TEST(its answer includes the mpv path),CLEAR_SOURCES,REQUEST_PLAYLIST_NAVIGATION. Web pages cannot message the background, and FastStream's content script never sends these, so this is hardening (a compromised content process), not a page exploit.MessageSendersnow classifies every answered type as'own'(FastStream's pages only) or'any'(content scripts too), read before any handler, replacing the five inline checks.backgroundMessages.test.mjskeeps it complete: every answered type is listed, no listed type is stale, and no type a content script sends is'own'. The background test harness sends an'own'message from the player page unless a test names another sender.Tests
backgroundMessages.test.mjs, aCLEAR_SOURCES-from-a-page case; removing the gate fails 4 tests.reload-keeps-bufferfailed in the full parallel e2e run (one segment that was still downloading at the reload was asked for again), and passes alone twice on this branch and twice on main: a timing race of the spec under load, not this change.🤖 Generated with Claude Code