The no-mention-of-pornhub branch stopped finding plain <video> elements on
pages like thisvid.com. Two site-agnostic causes, both fixed without any
site-specific references:
1. Predicate over-rejection: isValidManifestUrl (and the nested isManifestUrl
in m3u8DeepProbeFn) ran the placeholder/`%`/trailing-slash rejections
BEFORE the concrete media signals. thisvid serves its direct MP4 WITH a
trailing slash (.../14644093.mp4/?rnd=...), so `path.endsWith('/')`
rejected a real, fetchable source. Concrete media signals (.mp4/.webm/.ogv/
.mpd/.m4s/.m3u8/.hlsvod//hls/) now win outright, so a coincidental '%' or
trailing slash never sinks a real source — while genuine route templates
(/playlists/, /playlist/%1%/, /videos/{id}/) are still rejected.
2. Runtime cause on ad-iframe-heavy pages: scrapeTab ran only a MAIN-world
scrape. A MAIN-world + allFrames injection can reject on pages with
sandboxed/opaque-origin ad iframes, returning 0 videos even when a <video>
is visible. scrapeTab now falls back to an isolated-world scrape (no `world`
key — always permitted) when the MAIN-world run finds nothing. The per-frame
reduction was extracted into a shared reduceScrapeFrames helper.
Adds __tests__/simple_video.test.mjs: a thisvid isValidManifestUrl battery
(trailing-slash MP4 accepted, templates still rejected, %2B/%2F tokens
preserved) plus a structural guard that scrapeTab keeps both a MAIN-world
primary and an isolated-world fallback.
Co-Authored-By: Claude <noreply@anthropic.com>
kfj001andClaude
0030d031f1