Timo
75a9ba5d3d
Google Drive and YummyAnime host their player in a cross-origin iframe. The 3.1.2 targeting work reached those frames but misdiagnosed and destabilized them in four separate ways. No manifest permission is added or restored; webNavigation stays removed. Access diagnosis was inferred, not measured. Every frame probe error was swallowed, and any origin that failed to answer was reported as missing host access. A slow or still-loading player frame therefore produced "Host access required for youtube.googleapis.com" for an origin the extension already held. The resolver now asks permissions.contains() before raising an access error, and treats a granted-but-unresponsive origin as a retry, not a user decision. Probes were unbounded. Every executeScript in the resolver now runs under a timeout, so one unreachable frame can no longer stall an activation, and the retry budget drops from eight passes to three. The chat overlay followed the player into its frame, which rendered it on top of the video and scoped closing and minimizing to that frame. It is now always installed in the tab's top document, with all chat traffic routed to frame 0, while only the playback controller goes into the selected media frame. Nested targets reactivated continuously. Every heartbeat and content event revalidated the target with a full teardown and reinjection, and the media monitor treated ordinary play, pause and buffering as frame layout changes. Both paths now reactivate only when the selected frame or document actually moves. Also restores the audio-route retention that keeps a deselected tab audible: createMediaElementSource() can only be called once per element, so a reinjected content script must adopt the existing route rather than rebuild it. Verified with 90 unit tests, 40 browser E2E tests including two new Drive-shaped fixtures that assert the controller lands in the player frame while the chat stays in the top document, and npm run verify. 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.