Adds 4 regression tests:
- vite.config.ts entry modules must exist as source files
- content.js must NOT use inline script injection (textContent)
- interceptors.js must be a standalone IIFE file
- manifest.json content_scripts must reference content.js
Prevents future build-breaking phantom entry point errors
(the probeFn.js/scrapeFn.js issue kfj001 hit).
These files were added as Rollup entry points but never created as actual
source files — probeFn and scrapeFn are defined inline in index.js.
The missing entry points caused "Could not resolve entry module" on build.
The inline script.textContent injection in content.js violated the
strict CSP on sites like Pornhub ('script-src' without 'unsafe-inline').
Move interceptor code to a separate interceptors.js file and inject
via script.src = chrome.runtime.getURL('interceptors.js'). Chrome
treats extension-originated <script src> as content scripts — not
as page inline code — so the page's CSP does not apply.
- New src/inject/interceptors.js with all main-world interceptor code
- content.js now creates <script src> instead of <script textContent>
- Vite config updated to build interceptors.js to dist/
- Defensive null check on video.play() return value (jsdom returns undefined)
- Fix test mock: win.Hls (not win.HLS) to match viewer.js window.Hls reference
- All 39/39 tests now pass
- Run scrapeFn in main frame only to avoid iframe noise (23 thumbnails)
- Deep-walk player objects up to depth 5 for .m3u8 URLs
- Always include mediaType and hlsManifest in stored items
- When blob URL detected, substitute with HLS manifest from probe
- Add integration tests for storage pipeline and viewer rendering
- Add eslintignore for dist/
- Query HLS data structures directly from page JS state per tab
- Strategies: video element HLS instances, window-level player vars,
intercepted data, inline scripts, global config objects, content script
- Fixed merge logic: index.js now correctly processes interceptedManifests
and hlsQueryResults instead of non-existent playerData
- Skip blob: URLs in DOM scan (HLS-internal, can't be played directly)
- Only attach HLS manifest when actually detected for that tab
Previous approach (DOM snapshot via executeScript) failed on Pornhub because:
- Video player loads asynchronously via JavaScript
- HLS manifest arrives via XHR/fetch AFTER page render
- <video> element only shows blob: URL, not the actual manifest
New approach:
- Content script injects interceptor into MAIN world at document_start
- Interceptor patches XMLHttpRequest and fetch() to capture .m3u8 URLs
- Periodic DOM scans detect HLS player instances on <video> elements
- Global config object scanning for embedded stream URLs
- Popup queries content script via chrome.tabs.sendMessage for real-time data
- If no DOM videos found but content script has data, create entries from intercepted sources
Changes:
- content.js: Full rewrite with main-world injection + XHR/fetch interception
- index.js: Query content scripts via messages, merge with DOM snapshot
- manifest.json: all_frames + document_start for early injection
- Strategy 1: scan inline <script> blocks for .m3u8 URLs (skip subtitles/captions)
- Strategy 2: check video element HLS player instances (hlsInstance, _hls)
- Strategy 3: probe common global config objects (hlsConfig, playerConfig, etc.)
- Storage items now include hlsManifest and mediaType fields
- When HLS detected and src is blob:/empty, promote manifest URL to primary
- Backward compatible: direct MP4 entries unaffected
- Remove the hardcoded 4-tab limit in the find-videos flow
- Add per-tab try/catch so inaccessible tabs are skipped gracefully
- Filter out tabs that produced no frames from the dedup pipeline
- Update button label and status messages accordingly
robot
kfj001
robot