Timo
226453fd45
Reported as "Receiving end does not exist" with targetReady true and no activation errors: the election named a frame the player had already torn down. Three defects were stacked, each hidden by the one in front of it. The election was never released. getReadyTabVideoState() recovered through the guarded refresh, which reports "unchanged" when no video is reachable, so the stale frameId/documentId survived; adoption compounded it by setting hasVideo, after which the target only moves on a frame change. An unreachable content script — as opposed to a page that simply has no video yet — now releases the frame election back to the top frame. The tab selection is never touched. Switching frames destroyed the top frame's scripts. Promoting the target out of frame 0 called deactivateTargetTab() on the previous target, which sent TARGET_DEACTIVATE to frame 0 and tore down its content script and the chat overlay with it. That is why chat delivery failed after promotion, and why releasing the election pointed at an empty frame. An in-tab frame switch now leaves the top frame alone. Discovery could deadlock. Monitors announce new players, but a rebuilt frame is a new document with no monitor, so the video created in it was never reported — and nothing then triggered the upkeep that would have installed one. Monitors are reinstalled on every lifecycle notification with a trailing-edge debounce, and a bounded discovery poll breaks the cycle when no notification arrives at all: 2s, capped, only while a tab is selected with no video found, stopping the moment one is. The new browser test adopts a nested player, destroys its document the way the real player does, and asserts both the release and that the rebuilt player is picked up again without touching the popup. It was flaky until the deadlock was closed, and now passes repeatedly at a stable 8.3s. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Extension E2E smoke tests
Browser-level tests for the parts that unit tests cannot reach: which <video>
the extension picks on a real page, and whether the packed extension gets far
enough to control it.
npm run test:e2e:install # once, downloads the browsers
npm run build:extension # extension.spec.mjs loads dist/chrome
npm run test:e2e
Layout
| Path | Purpose |
|---|---|
detection.spec.mjs |
Runs the shipped findVideo() against the fixture pages |
extension.spec.mjs |
Loads dist/chrome, injects into a tab, applies remote play/pause/seek |
fixture-server.mjs |
Static server for the fixtures, with byte-range support for media |
fixtures/pages/ |
One page per scenario |
fixtures/media/ |
Small generated clips (see below) |
helpers/content-source.mjs |
Lifts the real finder out of extension/content.js |
Two rules worth keeping
The specs run the shipped source, not a copy. helpers/content-source.mjs
extracts findVideo and its ranking helpers straight out of
extension/content.js. A fixture that passes against a reimplementation would
prove nothing about the extension. If you split the finder into more functions,
add them to VIDEO_FINDER_EXPORTS there and to VIDEO_FINDER_PARTS in
scripts/test-content-video-finder.cjs, or the extraction fails loudly.
Each fixture marks its own answer. The element that must win carries
data-expected; videos that have to be playing carry data-autoplay, and
ready.js holds the page back until metadata and playback have settled. The
specs assert those preconditions before judging the finder, so a broken fixture
reads as a broken fixture instead of a scoring regression.
Scenarios
| Fixture | What it pins down |
|---|---|
simple-player.html |
The ordinary case |
iframe-player.html |
Player inside a same-origin frame, empty top document |
late-frame.html |
Player frame attached after the page settled |
shadow-player.html |
Player in a shadow root, tiny teaser in the light DOM |
muted-player.html |
Mute must not disqualify the only player |
hidden-preload.html |
A display:none preload still reports 1080p; it must lose |
ad-frame.html |
1080p asset in a 300x250 ad slot must lose to the real player |
background-loop.html |
Silent looping hero must lose despite being the largest |
multi-player.html |
Between equal players, the playing one wins |
sourceless.html |
A large <video> with no source can never be the player |
nested-frame.html |
Player two frame levels down |
reloading-frame.html |
Frame that swaps its document, with no mutation in the top one |
Benchmark
bench-finder.mjs is not a spec, because timings are machine dependent and
would only add noise to CI. Run it by hand when the finder changes:
node tests/e2e/fixture-server.mjs 4173 & node tests/e2e/bench-finder.mjs
It measures the shipped finder (lifted from content.js) against the
pre-v3.1.0 formula, which is transcribed inside the script since that code no
longer exists in the tree.
Regenerating the media
Solid-colour clips, a few KB each, committed so the suite needs no network:
ffmpeg -y -f lavfi -i "color=c=blue:s=1920x1080:d=30:r=10" -c:v libx264 -preset veryfast -crf 45 -pix_fmt yuv420p -movflags +faststart fixtures/media/player-1080p-30s.mp4
Same command with green/854x480/12, red/640x360/5 and gray/1280x720/3 for
the other three.