refactor: decouple from site-specific CDN references #5

Merged
kfj001 merged 11 commits from feature/no_mention_of_pornhub into master 2026-08-30 17:07:52 -07:00
8 changed files with 356 additions and 291 deletions
Showing only changes of commit 66c621825f - Show all commits

No files matched your search

+1 -1
View File
@@ -45,7 +45,7 @@ describe('Config: build integrity', () => {
if (codeOnly.includes('textContent')) {
throw new Error(
'content.js uses inline script injection (textContent). ' +
'Sites like Pornhub block inline scripts via CSP. Use script.src instead.'
'Some sites block inline scripts via CSP. Use script.src instead.'
);
}
if (!codeOnly.includes('script.src') || !codeOnly.includes('chrome.runtime.getURL')) {
+1 -1
View File
@@ -940,7 +940,7 @@ describe('HLS QA: Configuration and resource management', () => {
Review

[BLOCKING] F1
This new suite hangs the entire npm test runner (>30s at 100% CPU, exit 124; reproduced in isolation). runProbeWin evaluates m3u8DeepProbeFn in a live JSDOM window; Strategy H (src/viewer/index.js:484) does for (const key of Object.keys(window)) { walk(window[key], ...) } and window/_parent/_top/frames/_globalObject/_globalProxy are circular Proxy objects. walk (index.js:161) has a depth cap of 5 but NO visited-set / cycle detection, so it recurses unboundedly over thousands of proxied window keys and never returns. Because tests/run.mjs loads hls_qa.test.mjs, npm test never completes -> the repo's canonical test command is broken.
Suggested fix: Give the walker a visited set (WeakSet) so each object is walked at most once: const seen = new WeakSet(); function walk(obj,...){ if (obj && typeof obj==='object'){ if(seen.has(obj)) return; seen.add(obj);} ... }. Additionally cap Strategy H's window-key scan (window has hundreds of keys; only the handful of genuine player globals matter) — e.g. skip built-in global keys or cap the scan. Alternatively, scope the new test so it stubs only the window globals under test (pageContext, kvsplayer, __goon_plugin_data) instead of a full JSDOM window, avoiding the circular globals entirely.

[BLOCKING] F1 This new suite hangs the entire `npm test` runner (>30s at 100% CPU, exit 124; reproduced in isolation). runProbeWin evaluates m3u8DeepProbeFn in a live JSDOM window; Strategy H (src/viewer/index.js:484) does `for (const key of Object.keys(window)) { walk(window[key], ...) }` and window/_parent/_top/frames/_globalObject/_globalProxy are circular Proxy objects. `walk` (index.js:161) has a depth cap of 5 but NO visited-set / cycle detection, so it recurses unboundedly over thousands of proxied window keys and never returns. Because __tests__/run.mjs loads hls_qa.test.mjs, `npm test` never completes -> the repo's canonical test command is broken. **Suggested fix:** Give the walker a visited set (WeakSet) so each object is walked at most once: `const seen = new WeakSet(); function walk(obj,...){ if (obj && typeof obj==='object'){ if(seen.has(obj)) return; seen.add(obj);} ... }`. Additionally cap Strategy H's window-key scan (window has hundreds of keys; only the handful of genuine player globals matter) — e.g. skip built-in global keys or cap the scan. Alternatively, scope the new test so it stubs only the window globals under test (pageContext, kvsplayer, __goon_plugin_data) instead of a full JSDOM window, avoiding the circular globals entirely.
Review

[BLOCKING] F1
This new suite hangs the entire npm test runner (>30s at 100% CPU, exit 124; reproduced in isolation). runProbeWin evaluates m3u8DeepProbeFn in a live JSDOM window; Strategy H (src/viewer/index.js:484) does for (const key of Object.keys(window)) { walk(window[key], ...) } and window/_parent/_top/frames/_globalObject/_globalProxy are circular Proxy objects. walk (index.js:161) has a depth cap of 5 but NO visited-set / cycle detection, so it recurses unboundedly over thousands of proxied window keys and never returns. Because tests/run.mjs loads hls_qa.test.mjs, npm test never completes -> the repo's canonical test command is broken.
Suggested fix: Give the walker a visited set (WeakSet) so each object is walked at most once: const seen = new WeakSet(); function walk(obj,...){ if (obj && typeof obj==='object'){ if(seen.has(obj)) return; seen.add(obj);} ... }. Additionally cap Strategy H's window-key scan (window has hundreds of keys; only the handful of genuine player globals matter) — e.g. skip built-in global keys or cap the scan. Alternatively, scope the new test so it stubs only the window globals under test (pageContext, kvsplayer, __goon_plugin_data) instead of a full JSDOM window, avoiding the circular globals entirely.

[BLOCKING] F1 This new suite hangs the entire `npm test` runner (>30s at 100% CPU, exit 124; reproduced in isolation). runProbeWin evaluates m3u8DeepProbeFn in a live JSDOM window; Strategy H (src/viewer/index.js:484) does `for (const key of Object.keys(window)) { walk(window[key], ...) }` and window/_parent/_top/frames/_globalObject/_globalProxy are circular Proxy objects. `walk` (index.js:161) has a depth cap of 5 but NO visited-set / cycle detection, so it recurses unboundedly over thousands of proxied window keys and never returns. Because __tests__/run.mjs loads hls_qa.test.mjs, `npm test` never completes -> the repo's canonical test command is broken. **Suggested fix:** Give the walker a visited set (WeakSet) so each object is walked at most once: `const seen = new WeakSet(); function walk(obj,...){ if (obj && typeof obj==='object'){ if(seen.has(obj)) return; seen.add(obj);} ... }`. Additionally cap Strategy H's window-key scan (window has hundreds of keys; only the handful of genuine player globals matter) — e.g. skip built-in global keys or cap the scan. Alternatively, scope the new test so it stubs only the window globals under test (pageContext, kvsplayer, __goon_plugin_data) instead of a full JSDOM window, avoiding the circular globals entirely.
it('should vendor HLS bundle locally (not use CDN — avoids CSP blocks)', () => {
// Viewer loads hls.js from extension origin via chrome.runtime.getURL('hls.min.js')
// instead of a CDN — sites like Pornhub restrict script-src to 'self', blocking
Review

[BLOCKING] F1
This new suite hangs the entire npm test runner (>30s at 100% CPU, exit 124; reproduced in isolation). runProbeWin evaluates m3u8DeepProbeFn in a live JSDOM window; Strategy H (src/viewer/index.js:484) does for (const key of Object.keys(window)) { walk(window[key], ...) } and window/_parent/_top/frames/_globalObject/_globalProxy are circular Proxy objects. walk (index.js:161) has a depth cap of 5 but NO visited-set / cycle detection, so it recurses unboundedly over thousands of proxied window keys and never returns. Because tests/run.mjs loads hls_qa.test.mjs, npm test never completes -> the repo's canonical test command is broken.
Suggested fix: Give the walker a visited set (WeakSet) so each object is walked at most once: const seen = new WeakSet(); function walk(obj,...){ if (obj && typeof obj==='object'){ if(seen.has(obj)) return; seen.add(obj);} ... }. Additionally cap Strategy H's window-key scan (window has hundreds of keys; only the handful of genuine player globals matter) — e.g. skip built-in global keys or cap the scan. Alternatively, scope the new test so it stubs only the window globals under test (pageContext, kvsplayer, __goon_plugin_data) instead of a full JSDOM window, avoiding the circular globals entirely.

[BLOCKING] F1 This new suite hangs the entire `npm test` runner (>30s at 100% CPU, exit 124; reproduced in isolation). runProbeWin evaluates m3u8DeepProbeFn in a live JSDOM window; Strategy H (src/viewer/index.js:484) does `for (const key of Object.keys(window)) { walk(window[key], ...) }` and window/_parent/_top/frames/_globalObject/_globalProxy are circular Proxy objects. `walk` (index.js:161) has a depth cap of 5 but NO visited-set / cycle detection, so it recurses unboundedly over thousands of proxied window keys and never returns. Because __tests__/run.mjs loads hls_qa.test.mjs, `npm test` never completes -> the repo's canonical test command is broken. **Suggested fix:** Give the walker a visited set (WeakSet) so each object is walked at most once: `const seen = new WeakSet(); function walk(obj,...){ if (obj && typeof obj==='object'){ if(seen.has(obj)) return; seen.add(obj);} ... }`. Additionally cap Strategy H's window-key scan (window has hundreds of keys; only the handful of genuine player globals matter) — e.g. skip built-in global keys or cap the scan. Alternatively, scope the new test so it stubs only the window globals under test (pageContext, kvsplayer, __goon_plugin_data) instead of a full JSDOM window, avoiding the circular globals entirely.
// instead of a CDN — sites that restrict script-src to 'self' block
Review

[BLOCKING] F1
This new suite hangs the entire npm test runner (>30s at 100% CPU, exit 124; reproduced in isolation). runProbeWin evaluates m3u8DeepProbeFn in a live JSDOM window; Strategy H (src/viewer/index.js:484) does for (const key of Object.keys(window)) { walk(window[key], ...) } and window/_parent/_top/frames/_globalObject/_globalProxy are circular Proxy objects. walk (index.js:161) has a depth cap of 5 but NO visited-set / cycle detection, so it recurses unboundedly over thousands of proxied window keys and never returns. Because tests/run.mjs loads hls_qa.test.mjs, npm test never completes -> the repo's canonical test command is broken.
Suggested fix: Give the walker a visited set (WeakSet) so each object is walked at most once: const seen = new WeakSet(); function walk(obj,...){ if (obj && typeof obj==='object'){ if(seen.has(obj)) return; seen.add(obj);} ... }. Additionally cap Strategy H's window-key scan (window has hundreds of keys; only the handful of genuine player globals matter) — e.g. skip built-in global keys or cap the scan. Alternatively, scope the new test so it stubs only the window globals under test (pageContext, kvsplayer, __goon_plugin_data) instead of a full JSDOM window, avoiding the circular globals entirely.

[BLOCKING] F1 This new suite hangs the entire `npm test` runner (>30s at 100% CPU, exit 124; reproduced in isolation). runProbeWin evaluates m3u8DeepProbeFn in a live JSDOM window; Strategy H (src/viewer/index.js:484) does `for (const key of Object.keys(window)) { walk(window[key], ...) }` and window/_parent/_top/frames/_globalObject/_globalProxy are circular Proxy objects. `walk` (index.js:161) has a depth cap of 5 but NO visited-set / cycle detection, so it recurses unboundedly over thousands of proxied window keys and never returns. Because __tests__/run.mjs loads hls_qa.test.mjs, `npm test` never completes -> the repo's canonical test command is broken. **Suggested fix:** Give the walker a visited set (WeakSet) so each object is walked at most once: `const seen = new WeakSet(); function walk(obj,...){ if (obj && typeof obj==='object'){ if(seen.has(obj)) return; seen.add(obj);} ... }`. Additionally cap Strategy H's window-key scan (window has hundreds of keys; only the handful of genuine player globals matter) — e.g. skip built-in global keys or cap the scan. Alternatively, scope the new test so it stubs only the window globals under test (pageContext, kvsplayer, __goon_plugin_data) instead of a full JSDOM window, avoiding the circular globals entirely.
// cross-origin <script src> injection from CDN URLs.
if (!viewerSource.includes("chrome.runtime.getURL('hlds.js')")) {
throw new Error('viewer.js should load hlds.js from extension origin, not CDN');
Review

[BLOCKING] F1
This new suite hangs the entire npm test runner (>30s at 100% CPU, exit 124; reproduced in isolation). runProbeWin evaluates m3u8DeepProbeFn in a live JSDOM window; Strategy H (src/viewer/index.js:484) does for (const key of Object.keys(window)) { walk(window[key], ...) } and window/_parent/_top/frames/_globalObject/_globalProxy are circular Proxy objects. walk (index.js:161) has a depth cap of 5 but NO visited-set / cycle detection, so it recurses unboundedly over thousands of proxied window keys and never returns. Because tests/run.mjs loads hls_qa.test.mjs, npm test never completes -> the repo's canonical test command is broken.
Suggested fix: Give the walker a visited set (WeakSet) so each object is walked at most once: const seen = new WeakSet(); function walk(obj,...){ if (obj && typeof obj==='object'){ if(seen.has(obj)) return; seen.add(obj);} ... }. Additionally cap Strategy H's window-key scan (window has hundreds of keys; only the handful of genuine player globals matter) — e.g. skip built-in global keys or cap the scan. Alternatively, scope the new test so it stubs only the window globals under test (pageContext, kvsplayer, __goon_plugin_data) instead of a full JSDOM window, avoiding the circular globals entirely.

[BLOCKING] F1 This new suite hangs the entire `npm test` runner (>30s at 100% CPU, exit 124; reproduced in isolation). runProbeWin evaluates m3u8DeepProbeFn in a live JSDOM window; Strategy H (src/viewer/index.js:484) does `for (const key of Object.keys(window)) { walk(window[key], ...) }` and window/_parent/_top/frames/_globalObject/_globalProxy are circular Proxy objects. `walk` (index.js:161) has a depth cap of 5 but NO visited-set / cycle detection, so it recurses unboundedly over thousands of proxied window keys and never returns. Because __tests__/run.mjs loads hls_qa.test.mjs, `npm test` never completes -> the repo's canonical test command is broken. **Suggested fix:** Give the walker a visited set (WeakSet) so each object is walked at most once: `const seen = new WeakSet(); function walk(obj,...){ if (obj && typeof obj==='object'){ if(seen.has(obj)) return; seen.add(obj);} ... }`. Additionally cap Strategy H's window-key scan (window has hundreds of keys; only the handful of genuine player globals matter) — e.g. skip built-in global keys or cap the scan. Alternatively, scope the new test so it stubs only the window globals under test (pageContext, kvsplayer, __goon_plugin_data) instead of a full JSDOM window, avoiding the circular globals entirely.
Review

[BLOCKING] F1
This new suite hangs the entire npm test runner (>30s at 100% CPU, exit 124; reproduced in isolation). runProbeWin evaluates m3u8DeepProbeFn in a live JSDOM window; Strategy H (src/viewer/index.js:484) does for (const key of Object.keys(window)) { walk(window[key], ...) } and window/_parent/_top/frames/_globalObject/_globalProxy are circular Proxy objects. walk (index.js:161) has a depth cap of 5 but NO visited-set / cycle detection, so it recurses unboundedly over thousands of proxied window keys and never returns. Because tests/run.mjs loads hls_qa.test.mjs, npm test never completes -> the repo's canonical test command is broken.
Suggested fix: Give the walker a visited set (WeakSet) so each object is walked at most once: const seen = new WeakSet(); function walk(obj,...){ if (obj && typeof obj==='object'){ if(seen.has(obj)) return; seen.add(obj);} ... }. Additionally cap Strategy H's window-key scan (window has hundreds of keys; only the handful of genuine player globals matter) — e.g. skip built-in global keys or cap the scan. Alternatively, scope the new test so it stubs only the window globals under test (pageContext, kvsplayer, __goon_plugin_data) instead of a full JSDOM window, avoiding the circular globals entirely.

[BLOCKING] F1 This new suite hangs the entire `npm test` runner (>30s at 100% CPU, exit 124; reproduced in isolation). runProbeWin evaluates m3u8DeepProbeFn in a live JSDOM window; Strategy H (src/viewer/index.js:484) does `for (const key of Object.keys(window)) { walk(window[key], ...) }` and window/_parent/_top/frames/_globalObject/_globalProxy are circular Proxy objects. `walk` (index.js:161) has a depth cap of 5 but NO visited-set / cycle detection, so it recurses unboundedly over thousands of proxied window keys and never returns. Because __tests__/run.mjs loads hls_qa.test.mjs, `npm test` never completes -> the repo's canonical test command is broken. **Suggested fix:** Give the walker a visited set (WeakSet) so each object is walked at most once: `const seen = new WeakSet(); function walk(obj,...){ if (obj && typeof obj==='object'){ if(seen.has(obj)) return; seen.add(obj);} ... }`. Additionally cap Strategy H's window-key scan (window has hundreds of keys; only the handful of genuine player globals matter) — e.g. skip built-in global keys or cap the scan. Alternatively, scope the new test so it stubs only the window globals under test (pageContext, kvsplayer, __goon_plugin_data) instead of a full JSDOM window, avoiding the circular globals entirely.
+2 -1
View File
@@ -8,7 +8,8 @@
"tabs",
"scripting",
"webRequest",
"declarativeNetRequest"
"declarativeNetRequest",
"extraHeaders"
],
"host_permissions": [
"<all_urls>"
+214 -150
View File
@@ -23,13 +23,12 @@ function isHlsManifest(url) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
u.includes('/playlist.m3u') || u.includes('/manifest');
}
// === STRATEGY 8: Network-level fallback — log ALL phncdn.com and video-related requests ===
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Pornhub's es6player generates HLS manifests in-memory with zero .m3u8 network requests.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// However, the player still fetches video segments from phncdn.com. By logging all phncdn
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// requests we can: (a) confirm HLS activity via segment patterns, (b) reconstruct manifest
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// URLs from segment paths, (c) detect CDN response headers that reveal playlist endpoints.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const PHNCDN_HOSTS = ['phncdn.com', 'pornhubpremium.com', 'cdn.pornhub.com'];
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// === STRATEGY 8: Network-level fallback — log video requests across any CDN ===
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Some players generate HLS manifests in-memory and make zero .m3u8 network
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// requests, only fetching video segments from a CDN. By logging every video-like
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// request (any host) we can: (a) confirm HLS activity via segment patterns,
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// (b) reconstruct manifest URLs from segment paths, (c) detect CDN response
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// headers that reveal playlist endpoints. No site-specific host list.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const VIDEO_PATH_PATTERNS = ['/hls/', '/dash/', '/video/', '/segment', '/media/', '/stream'];
function isVideoRequest(url) {
@@ -47,7 +46,7 @@ async function persistVideoRequest(tabId, url) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
try {
const stored = await chrome.storage.local.get(key);
const arr = stored[key] || [];
// Avoid duplicates — phncdn segments come in rapid succession
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Avoid duplicates — video segments come in rapid succession
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!arr.some(r => r === url)) {
arr.push(url);
// Keep last 200 requests per tab (enough to detect segment patterns)
@@ -59,23 +58,25 @@ async function persistVideoRequest(tabId, url) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
}
// --- phncdn token / URL helpers ------------------------------------------
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// --- Token / URL helpers ------------------------------------------
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
//
// The phncdn auth token (h= / hash= / hdnea=) is base64 and its %-encoded
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// A media CDN's auth token (h= / hash= / hdnea=) is base64 and its %-encoded
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// escapes are significant: a `+` decoded to a space corrupts it, which is what
// produces the 410 Gone the live player avoids by sending `%2B`. So every
// helper below keeps the query string RAW — it is never passed through
// URLSearchParams (which decodes + -> space).
// Extract the phncdn videoId from a /hls/videos/ URL; '' if it isn't one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Path shape: /hls/videos/{year}/{subdir}/{videoId}/{variant}/...
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
function extractVideoId(url) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!url || !url.includes('/hls/videos/')) return '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Group key for a video's URL: the path directory holding its variant/segment
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// (the last non-file path segment of a CDN URL). Used to match the freshest
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// live URL by video, host-independent. '' when the URL is malformed.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
function extractGroupKey(url) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!url) return '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
try {
const path = new URL(url).pathname.split('/');
const hlsIdx = path.findIndex(p => p === 'hls');
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (hlsIdx === -1 || hlsIdx + 4 >= path.length) return '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return path[hlsIdx + 4];
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Drop the final (file/segment or manifest) segment; the remaining
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// directory joins into a key that is stable across a video's variants.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
path.pop();
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return path.join('/');
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
} catch {
return '';
}
@@ -99,28 +100,21 @@ function tokenExpirySeconds(rawQuery) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return secs;
}
// Build a manifest URL for a variant directory from a raw phncdn URL,
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// preserving the FULL variant path and the raw query (token encoding intact).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// /hls/videos/{year}/{subid}/{videoId}/{variant}/seg-1.ts ->
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// /hls/videos/{year}/{subid}/{videoId}/{variant}/master.m3u8
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// The variant directory (e.g. 720P_4000K_338337051.mp4) is MANDATORY — a master
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// playlist lives inside it; dropping it (the old bug) yields a 410. Returns ''
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// when the URL isn't a phncdn HLS URL with a complete variant path.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
function buildManifestForVariant(rawUrl) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!rawUrl || !rawUrl.includes('/hls/videos/')) return '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Build the parent manifest URL for a segment URL, keeping the FULL path to
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// the variant directory and the RAW query (token encoding intact). Swaps the
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// segment filename for a manifest filename in the same directory:
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// {host}/path/to/variant/seg-1.ts -> {host}/path/to/variant/master.m3u8
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// The variant directory is MANDATORY — a master playlist lives inside it;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// dropping it yields a 404/410. Returns '' for non-segment URLs.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
function buildManifestForVariant(url) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!url || !/\/seg-\d+/i.test(url)) return '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
try {
const path = rawUrl.split('?')[0];
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const parts = path.split('/');
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const hlsIdx = parts.findIndex(p => p === 'hls');
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Need hls, videos, year, subdir, videoId, variant (6 dirs).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (hlsIdx === -1 || hlsIdx + 5 >= parts.length) return '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const prefix = parts.slice(0, hlsIdx + 2).join('/'); // .../hls/videos
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const year = parts[hlsIdx + 2];
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const subid = parts[hlsIdx + 3];
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const videoId = parts[hlsIdx + 4];
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const variant = parts[hlsIdx + 5];
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const rawQuery = extractRawQuery(rawUrl);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return `${prefix}/${year}/${subid}/${videoId}/${variant}/master.m3u8${rawQuery ? '?' + rawQuery : ''}`;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const [pathPart, queryPart] = url.split('?');
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const idx = pathPart.lastIndexOf('/');
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (idx === -1) return '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const dir = pathPart.slice(0, idx); // variant directory
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const rawQuery = queryPart ? '?' + queryPart : '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return `${dir}/master.m3u8${rawQuery}`;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
} catch {
return '';
}
@@ -133,8 +127,7 @@ function reconstructManifestsFromSegments(segments) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const seen = new Set();
const manifests = [];
for (const url of segments) {
// Only handle HLS segment URLs: /hls/videos/{..}/{variant}/seg-N.ts
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!url.includes('/hls/videos/') || !/\/seg-\d+/.test(url)) continue;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Only handle video/segment URLs (e.g. .../seg-N.ts).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const manifestUrl = buildManifestForVariant(url);
if (manifestUrl && !seen.has(manifestUrl)) {
seen.add(manifestUrl);
@@ -144,10 +137,10 @@ function reconstructManifestsFromSegments(segments) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return manifests;
}
// Collect phncdn URLs across ALL tabs without a tabs.query match pattern (which
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// throws if the pattern is malformed). We scan every persisted vr_requests_ /
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Collect captured video URLs across ALL tabs without a tabs.query match pattern
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// (which throws if the pattern is malformed). We scan every persisted vr_requests_ /
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// wr_manifests_ key so the rescan works even if the live source tab is closed.
async function collectAllPhncdnUrls() {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
async function collectAllVideoUrls() {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const all = await chrome.storage.local.get();
const out = [];
for (const key of Object.keys(all)) {
@@ -158,21 +151,21 @@ async function collectAllPhncdnUrls() {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return out;
}
// For a videoId, return the freshest live phncdn URL (highest token expiry)
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// across all persisted tabs, preferring captured .m3u8 manifest URLs. null if
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// nothing usable is captured yet. Rescans use this to replace a stored URL that
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// now 410s with the newest token the live tab captured.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// For a group key, return the freshest live captured URL (highest token
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// expiry) across all persisted tabs, preferring captured .m3u8 manifest URLs.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// null if nothing usable is captured yet. Rescans use this to replace a
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// stored URL that now 410s with the newest token the live tab captured.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
//
// No tabs.query match pattern is used: '*pornhub.com*' is an INVALID pattern and
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// made this throw ("Invalid url pattern"), which silently dropped every rescan.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// No tabs.query match pattern is used: match patterns are brittle (a bad
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// pattern throws "Invalid url pattern" and silently drops every rescan).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// We scan persisted capture data instead, which is always available and
// sidesteps the match-Pattern API entirely.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
async function freshLiveForVideo(videoId, preferManifest) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// sidesteps the match-pattern API entirely.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
async function freshLiveForGroup(groupKey, preferManifest) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
let all;
try {
all = await collectAllPhncdnUrls();
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
all = await collectAllVideoUrls();
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
} catch (e) {
console.warn('[goon-bg] collectAllPhncdnUrls failed:', e && e.message ? e.message : e);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
console.warn('[goon-bg] collectAllVideoUrls failed:', e && e.message ? e.message : e);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
all = [];
}
@@ -180,19 +173,19 @@ async function freshLiveForVideo(videoId, preferManifest) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
let bestVariant = null, bestVariantExp = 0;
let bestTokenSource = null, bestTokenExp = 0;
for (const url of all) {
if (extractVideoId(url) !== videoId) continue;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (extractGroupKey(url) !== groupKey) continue;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const exp = tokenExpirySeconds(extractRawQuery(url));
if (url.includes('.m3u8')) {
if (exp > bestManifestExp) { bestManifestExp = exp; bestManifest = url; }
} else if (/\/seg-\d+/.test(url)) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
} else if (/\/seg-\d+/i.test(url)) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (exp > bestVariantExp) { bestVariantExp = exp; bestVariant = url; }
} else {
if (exp > bestTokenExp) { bestTokenExp = exp; bestTokenSource = url; }
}
}
// Prefer a captured manifest; else reconstruct the variant manifest; else
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// hand back a token source so the proxy can at least re-token a good path.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Prefer a captured manifest; else the best segment (reconstructable to a
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// manifest); else a token source so the proxy can re-token a good path.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (bestManifest) return bestManifest;
if (!preferManifest && bestVariant) return bestVariant;
if (!preferManifest && bestTokenSource) return bestTokenSource;
@@ -200,30 +193,34 @@ async function freshLiveForVideo(videoId, preferManifest) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return bestManifest || bestTokenSource || null;
}
// Cache freshest tokens per videoId so we don't query storage on every proxy
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// request. Keyed by videoId; values resolve once and are reused until a rescan
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Cache freshest tokens per group key so we don't query storage on every proxy
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// request. Keyed by group key; values resolve once and are reused until a rescan
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// (GOON_RESOLVE_MANIFEST) or a 410 forces an invalidation.
const tokenCache = new Map();
// Given a phncdn /hls/videos/ URL that arrives WITHOUT a query (hls.js drops the
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// relative-URL token when building sub-playslists/segments), inject the freshest
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// live token for that videoId. Returns the URL with a query appended, or the
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// original URL unchanged when no token is available yet.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Given a CDN URL that arrives WITHOUT a query (hls.js drops the relative-URL
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// token when building sub-playslists/segments), inject the freshest live token
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// for that group. Returns the URL with a query appended, or the original URL
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// unchanged when no token is available yet.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
async function injectFreshToken(url) {
if (!url || !url.includes('/hls/videos/')) return url;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!url) return url;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Already carries a token — leave it alone.
if (url.includes('?')) return url;
const videoId = extractVideoId(url);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!videoId) return url;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (tokenCache.has(videoId)) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const token = tokenCache.get(videoId);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
try {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const groupKey = extractGroupKey(url);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!groupKey) return url;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (tokenCache.has(groupKey)) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const token = tokenCache.get(groupKey);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return token ? url + '?' + token : url;
}
const fresh = await freshLiveForVideo(videoId, false);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const fresh = await freshLiveForGroup(groupKey, false);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const token = fresh ? extractRawQuery(fresh) : '';
tokenCache.set(videoId, token);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
console.log('[goon-bg] injectFreshToken for', videoId, videoId + '-> ' + (token ? token.substring(0, 40) + '…' : '(none captured)'));
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
tokenCache.set(groupKey, token);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
console.log('[goon-bg] injectFreshToken for', groupKey, (token ? token.substring(0, 40) + '…' : '(none captured)'));
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return token ? url + '?' + token : url;
} catch {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return url;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
// Clear the per-video token cache. Called on rescan so the next proxy fetches
@@ -234,21 +231,12 @@ chrome.webRequest.onBeforeRequest.addListener(
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
async (details) => {
if (details.tabId < 0) return;
const u = details.url.toLowerCase();
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const isPhncdn = PHNCDN_HOSTS.some(host => details.url.includes(host));
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const isVideo = isVideoRequest(details.url);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Log ALL phncdn.com requests regardless of path
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (isPhncdn) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
console.log('[goon-bg] webRequest: phncdn request in tab', details.tabId, ':', details.url.substring(0, 180));
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Log video-like requests from any host (CDN-agnostic).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (isVideoRequest(details.url)) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
console.log('[goon-bg] webRequest: video request in tab', details.tabId, ':', details.url.substring(0, 180));
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
await persistVideoRequest(details.tabId, details.url);
}
// Log video-like requests from any host
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (isVideo && !isPhncdn) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
console.log('[goon-bg] webRequest: video request in tab', details.tabId, ':', details.url.substring(0, 150));
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Also capture HLS manifest URLs (original logic)
if (!isHlsManifest(details.url)) return;
@@ -271,74 +259,144 @@ chrome.webRequest.onBeforeRequest.addListener(
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Clean up stale entries when tabs are closed
chrome.tabs.onRemoved.addListener(async (tabId) => {
const keys = ['wr_manifests_' + tabId, 'vr_requests_' + tabId];
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const keys = ['wr_manifests_' + tabId, 'vr_requests_' + tabId, 'goon_referers'];
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
try {
await chrome.storage.local.remove(keys);
} catch { /* ignore */ }
});
// === Force a pornhub Referer on every *.phncdn.com request ===
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// The phncdn video CDN (hv-h.phncdn.com, pix-fl.phncdn.com, ev-h.phncdn.com,
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// ... and the auth-token hosts) rejects any request whose Referer is not a
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// pornhub-origin with HTTP 412 (see round-1 curl test: `Referer:
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// https://www.pornhub.com/` -> 200, no referer -> 412). Origin is NOT the
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// gate (curl with a pornhub Referer and no Origin still 200s), so we only
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// rewrite Referer and never touch Origin.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// === Capture the provider-origin Referer per CDN host (CDN-agnostic) ===
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Some media CDNs reject requests whose `Referer` is not the provider page's
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// origin (HTTP 412). A fetch() CANNOT set `Referer` — it is a "forbidden
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// header" in the Fetch API, so a service-worker fetch() would send
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// `Referer: chrome-extension://<id>`, which the CDN rejects. The
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// declarativeNetRequest API rewrites request headers at the network layer, below
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// the Fetch API's restriction, and its rules apply to fetch() calls made inside
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// the SW.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
//
// A normal fetch() CANNOT set the `Referer` header — it is a "forbidden
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// header" in the Fetch API, so a service-worker fetch() gets
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// `Referer: chrome-extension://<id>`, which the CDN rejects (412). The
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// declarativeNetRequest API rewrites request headers at the network layer,
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// below the Fetch API's forbidden-header restriction, and — per Chrome docs —
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// these rules DO apply to fetch() calls made inside the service worker. So we
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// force a pornhub referer on phncdn.com; the GOON_PROXY_FETCH handler in the
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// SW then fetches the manifest + segments successfully.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// We cannot hardcode a target referer: the proxy is invoked from the viewer
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// (a different origin than the source page), and a DNR rule cannot read a live
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// page's origin. So we capture the referer that the REAL page uses for its video
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// requests — via chrome.webRequest.onBeforeSendHeaders, which sees the request
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// headers the browser already built — and persist it per CDN host. The
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// GOON_PROXY_FETCH handler then installs a DNR rule that re-inserts that
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// captured referer for just that host, so the proxy's fetch() is accepted.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// This requires no knowledge of any particular site.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const REFERER_RULE_ID = 9001;
const REFERER_RULE = {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// host of a URL (CDN host, lowercased); '' when the URL is malformed.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
function hostOf(url) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!url) return '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
try { return new URL(url).host.toLowerCase(); } catch { return ''; }
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Best-effort origin for a host when no referer was captured for it. Used only
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// as a fallback; a captured referer always wins.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
function originFromHost(host) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return host ? 'https://' + host + '/' : '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Read the `Referer` request header (the browser may title-case it; the
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// `extraHeaders` option exposes it to MV3 onBeforeSendHeaders).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
function readReferer(headers) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!Array.isArray(headers)) return '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
for (const h of headers) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (h && h.name && h.name.toLowerCase() === 'referer') return h.value || '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Persist the captured referer per CDN host so the proxy can re-use it even
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// after this capture tab closes. Keyed by host so a proxy for that host can
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// look its referer up without knowing the source tab.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
async function persistReferer(host, referer) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!host || !referer) return;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
try {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const stored = await chrome.storage.local.get('goon_referers');
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const map = stored['goon_referers'] || {};
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (map[host] === referer) return;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
map[host] = referer;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
await chrome.storage.local.set({ goon_referers: map });
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
} catch (e) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
console.warn('[goon-bg] persistReferer failed:', e && e.message ? e.message : e);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Look up the referer captured for a host. '' when none has been captured.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
async function getReferer(host) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!host) return '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
try {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const stored = await chrome.storage.local.get('goon_referers');
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return (stored['goon_referers'] || {})[host] || '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
} catch {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return '';
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Capture the referer the real page sends for its video requests.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
chrome.webRequest.onBeforeSendHeaders.addListener(
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
async (details) => {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (details.tabId < 0) return;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!isVideoRequest(details.url)) return;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const host = hostOf(details.url);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!host) return;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const referer = readReferer(details.requestHeaders);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (referer) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// The browser already built a referer from the source page — use it.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
await persistReferer(host, referer);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
} else {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// No referer was sent; assume the page's origin is the expected referer.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
await persistReferer(host, originFromHost(host));
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
},
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
{ urls: ['<all_urls>'], extraHeaders: ['Referer'] }
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Install (idempotently) a DNR rule that sets the captured referer for a given
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// CDN host. The value comes from capture (or a fallback origin), never a
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// hardcoded site. Scoped to the requested host so only proxy fetches for that
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// host get the rewritten header.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
async function ensureRefererRule(host, referer) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!host || !referer) return;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const api = chrome.declarativeNetRequest;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!api || typeof api.updateSessionRules !== 'function') {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
console.warn('[goon-bg] declarativeNetRequest unavailable; skipping referer rule');
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (refererRuleInstalled.has(host) && refererRuleInstalled.get(host) === referer) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
try {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
await api.updateSessionRules({
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
removeRuleIds: [REFERER_RULE_ID],
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
addRules: [{
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
id: REFERER_RULE_ID,
priority: 1,
action: {
type: 'modifyHeaders',
// `set` is allowed for any request header (only `append` is restricted to
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// a fixed allowlist). `referer` is the header the CDN checks.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// `set` is allowed for any request header (only `append` is restricted
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// to a fixed allowlist). `referer` is the header the CDN checks.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
requestHeaders: [
{ header: 'referer', operation: 'set', value: 'https://www.pornhub.com/' },
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
{ header: 'referer', operation: 'set', value: referer },
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
],
},
condition: {
// phncdn.com (host + subdomains) ONLY. Do NOT include pornhub.com: the
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// real page player's auth calls (api.pornhub.com) and its own segment
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// fetches must keep their browser-supplied Origin/Referer or playback
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// freezes. The proxy only ever fetches phncdn URLs.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
requestDomains: ['phncdn.com'],
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Host + subdomains ONLY, so only proxy fetches for this host get the
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// rewritten referer; the source page's own requests keep theirs.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
requestDomains: [host],
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
},
};
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Cached promise so concurrent proxy fetches share one rule install; a
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// transient failure is cleared so a later fetch retries.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
let refererRuleReady = null;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
async function ensureRefererRule() {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (refererRuleReady) return refererRuleReady;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
refererRuleReady = (async () => {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const api = chrome.declarativeNetRequest;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!api || typeof api.updateSessionRules !== 'function') {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
throw new Error('declarativeNetRequest.updateSessionRules unavailable');
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Idempotent: remove any stale copy of our rule, then add the fresh one.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
await api.updateSessionRules({
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
removeRuleIds: [REFERER_RULE_ID],
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
addRules: [REFERER_RULE],
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}],
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
});
console.log('[goon-bg] DNR referer rule installed for *.phncdn.com');
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
})();
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// If it failed, reset so the next call retries instead of caching the
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// rejected promise forever.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
refererRuleReady.catch(() => { refererRuleReady = null; });
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return refererRuleReady;
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
refererRuleInstalled.set(host, referer);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
console.log('[goon-bg] DNR referer rule installed for', host);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
} catch (e) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
console.warn('[goon-bg] ensureRefererRule failed:', e && e.message ? e.message : e);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
// Install eagerly on SW start so even the first proxy fetch is covered.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
ensureRefererRule();
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Track which host's referer is currently installed so repeated proxy fetches
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// for the same host don't reinstall the same rule.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const refererRuleInstalled = new Map();
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// === Message handlers for popup/data consumers ===
@@ -362,8 +420,8 @@ chrome.runtime.onMessage.addListener((message, _sender, sendResponse) => {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
return true;
}
case 'GOON_GET_PHNCDN_REQUESTS': {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Strategy 8: Return all phncdn.com requests for a tab, including reconstructed manifests
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
case 'GOON_GET_VIDEO_REQUESTS': {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Strategy 8: Return all video requests for a tab, including reconstructed manifests
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
(async () => {
const tabId = message.tabId;
const [segKey] = ['vr_requests_' + tabId];
@@ -385,7 +443,7 @@ chrome.runtime.onMessage.addListener((message, _sender, sendResponse) => {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
case 'GOON_RESOLVE_MANIFEST': {
// Resolve the freshest live phncdn manifest for the video in a stored
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Resolve the freshest live manifest for the video encoded in a stored
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// URL. The viewer calls this at startup and on a fatal network error:
// the live tab keeps rotating short-lived tokens, so the freshest
// captured manifest (highest expiry) replaces one that has 410'd.
@@ -394,14 +452,14 @@ chrome.runtime.onMessage.addListener((message, _sender, sendResponse) => {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
async function resolveFreshManifest(message, sendResponse) {
invalidateTokenCache();
const url = message.url || '';
const videoId = extractVideoId(url);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!videoId) { sendResponse({ ok: false, error: 'no videoId' }); return; }
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const groupKey = extractGroupKey(url);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (!groupKey) { sendResponse({ ok: false, error: 'no group key' }); return; }
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
try {
const fresh = await freshLiveForVideo(videoId, true);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
sendResponse({ ok: true, fresh, videoId, changed: !!(fresh && fresh !== url) });
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const fresh = await freshLiveForGroup(groupKey, true);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
sendResponse({ ok: true, fresh, groupKey, changed: !!(fresh && fresh !== url) });
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
} catch (e) {
console.warn('[goon-bg] resolveFreshManifest failed:', e && e.message ? e.message : e);
sendResponse({ ok: false, error: e && e.message ? e.message : String(e), videoId });
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
sendResponse({ ok: false, error: e && e.message ? e.message : String(e), groupKey });
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
}
resolveFreshManifest(message, sendResponse);
@@ -413,19 +471,25 @@ chrome.runtime.onMessage.addListener((message, _sender, sendResponse) => {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Returns base64-encoded response data. Used by the viewer when
// extension-origin requests to video CDNs are blocked by CORS.
//
// The phncdn CDN 412s requests without a pornhub Referer. A fetch()
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// can't set Referer itself (forbidden header — Chrome replaces it with
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// chrome-extension://...), so we install a declarativeNetRequest rule
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// that forces `Referer: https://www.pornhub.com/` at the network layer
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// for all *.phncdn.com requests (DNR applies to SW fetch() per Chrome
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// docs). Await it first so the very next fetch is covered.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// A fetch() can't set the Referer itself (forbidden header — Chrome
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// replaces it with chrome-extension://...), so a declarativeNetRequest
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// rule installs the captured provider-origin referer at the network
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// layer (DNR applies to SW fetch() per Chrome docs). The rule is
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// installed on demand for the requested host only.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
(async () => {
try {
await ensureRefererRule();
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const proxyHost = hostOf(message.url);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
if (proxyHost) {
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// Prefer the provider's real referer captured from the live
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// tab; fall back to a viewer-supplied or host-derived origin.
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const captured = await getReferer(proxyHost);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
const referer = captured || message.referer || originFromHost(proxyHost);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
await ensureRefererRule(proxyHost, referer);
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
}
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// hls.js resolves sub-playslists/segments relative to the master
// and can DROP the token query, handing us a token-less phncdn
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// URL that 410s. injectFreshToken supplies the freshest live token
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// for that videoId; the final `+` -> `%2B` pass keeps the
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// and can DROP the token query, handing us a token-less
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// URL that 410s. injectFreshToken supplies the freshest live
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// token for that video; the final `+` -> `%2B` pass keeps the
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
// (possibly injected or surviving) base64 token intact for the
// CDN's query parsing.
const resolved = await injectFreshToken(message.url || '');
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.

Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
Review

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).

Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
Review

[SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The extraHeaders permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
Suggested fix: Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.

[SHOULD-FIX] F2 Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism. **Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
+1 -1
View File
@@ -26,7 +26,7 @@
* Inject interceptors into the MAIN world at document_start.
*
* Uses script.src = chrome.runtime.getURL('interceptors.js') instead of
* script.textContent to bypass strict page CSP. Sites like Pornhub enforce
* script.textContent to bypass strict page CSP. Some sites enforce
* 'script-src' that blocks inline execution (textContent). Chrome treats
* extension-originated <script src="..."> as content scripts — not as
* page inline code — so the page's CSP does not apply.
+2 -1
View File
@@ -2,7 +2,8 @@
* interceptors.js — Main-world interceptors for HLS manifest detection.
*
* This file is injected into the main world via a <script src="..."> tag
* (NOT inline textContent) to bypass strict CSP on sites like Pornhub.
* (NOT inline textContent) to bypass strict CSP on sites that restrict
* script-src.
*
* When loaded as an external script from the extension origin, Chrome treats
* it as an extension content script — not as page inline code — so the
+52 -88
View File
@@ -320,7 +320,7 @@ function m3u8DeepProbeFn() {
probeLog('Strategy E (interceptor data): found', manifests.length - preECount, 'new manifests');
// Strategy F: Dynamic playlist fallback — scan video elements for Hls-like
// instances and extract ANY URL, not just .m3u8. Sites like Pornhub use
// instances and extract ANY URL, not just .m3u8. Some players use
// HLS.js dynamic playlists where the "manifest" is generated in-memory,
// so the URL might be a blob:, CDN endpoint, or data URI.
let strategyFCount = 0;
@@ -700,7 +700,7 @@ function dedupManifests(allManifests) {
'__goon_plugin_data': 0,
'content-script-intercept': 0,
'webRequest': 1,
'phncdn_reconstructed': 2,
'hls_reconstructed': 2,
'video._goon_hls_manifest': 3,
'inline-script': 99,
};
@@ -746,15 +746,15 @@ async function queryWebRequestManifests(tabId) {
}
/**
* Query the service worker for all phncdn.com requests captured by Strategy 8.
* Returns segments + reconstructed manifest URLs from segment patterns.
* Query the service worker for all video requests captured by Strategy 8,
* including reconstructed manifest URLs derived from segment patterns.
* @param {number} tabId
* @returns {Promise<{segments: Array, reconstructedManifests: Array, totalRequests: number}>}
*/
async function queryPhncdnRequests(tabId) {
async function queryVideoRequests(tabId) {
try {
const resp = await chrome.runtime.sendMessage({
type: 'GOON_GET_PHNCDN_REQUESTS',
type: 'GOON_GET_VIDEO_REQUESTS',
tabId: tabId,
});
return resp || { segments: [], reconstructedManifests: [], totalRequests: 0 };
@@ -765,7 +765,7 @@ async function queryPhncdnRequests(tabId) {
/**
* Scrape video elements from ALL frames in a tab.
* On sites like Pornhub, the video player lives inside an iframe — main-frame-only
* On many video sites the player lives inside an iframe — main-frame-only
* scraping sees zero <video> elements. Running allFrames catches them.
*
* Runs in the MAIN world so it can see page globals:
@@ -829,72 +829,34 @@ function filterManifests(manifests) {
(u.includes('/playlist') && !u.endsWith('.ts'));
});
// Reject fake reconstructed manifest paths.
// Real manifests are under /hls/videos/{year}/{subdir}/{videoId}/...
// Fakes look like: phncdn.com/videos/{id}/playlist.m3u8 or .../master.m3u8 (no /hls/)
const valid = actualManifests.filter(m => {
const u = m.url.toLowerCase();
try {
const urlObj = new URL(u);
// phncdn URLs must have /hls/ in the path — fake reconstructed paths lack it
if (u.includes('phncdn') || u.includes('pornhubcdn')) {
if (!urlObj.pathname.includes('/hls/') && !u.includes('?h=')) {
return false; // Fake: phncdn URL without /hls/ or auth query param
}
}
} catch {}
return true;
});
// If we have actual (non-fake) manifests, use them directly
// Reject clearly-fake manifest paths (see isValidManifestUrl).
const valid = actualManifests.filter(m => isValidManifestUrl(m.url));
if (valid.length > 0) {
return valid.map(m => ({ url: m.url }));
}
// No .m3u8 found — interceptors only captured .ts segments.
// Reconstruct the parent manifest URL from segment paths.
// Segment: https://ev-h.phncdn.com/hls/videos/202008/01/338337051/720P_4000K_338337051.mp4/seg-1-v1-a1.ts?h=tmrD...&e=1786932752&f=1
// Manifest: https://ev-h.phncdn.com/hls/videos/202008/01/338337051/720P_4000K_338337051.mp4/master.m3u8?h=tmrD...&e=1786932752&f=1
//
// Auth tokens (h, e, f or validfrom, validto, hash) are extracted from segment query params
// and reapplied to the reconstructed manifest URL. This is critical because CDN domains
// require auth — a path-only URL will be rejected with 403.
// No manifest found — interceptors only captured segment files. Reconstruct a
// manifest URL from each segment's directory, carrying over its auth query
// string intact (CDNs reject a path-only URL with 403). CDN-agnostic: the
// segment filename is swapped for a manifest filename in the same directory,
// e.g. .../variant/seg-1.ts?h=... -> .../variant/master.m3u8?h=...
const seen = new Set();
const reconstructed = [];
// A segment filename: numbered segment, or an .ts/.m4s/.aac media extension.
const SEG_RE = /(seg-\d+|\.(?:ts|m4s|aac)(?:$|\?))/i;
for (const m of manifests) {
const u = m.url.toLowerCase();
if (!u.includes('/hls/videos/') || !/\/seg-\d+/.test(u)) continue;
if (!SEG_RE.test(m.url)) continue;
try {
const urlObj = new URL(m.url);
// Skip non-phncdn hosts — we only reconstruct for known video CDNs
const host = urlObj.host.toLowerCase();
if (!host.includes('phncdn')) continue;
const pathParts = urlObj.pathname.split('/');
// Find the /hls/ marker and extract: hls/videos/{year}/{subdir}/{videoId}/{variant}/...
const hlsIdx = pathParts.findIndex(p => p === 'hls');
if (hlsIdx === -1 || hlsIdx + 5 >= pathParts.length) continue;
// Reconstruct with BOTH "hls" prefix AND variant directory included:
// segment: /hls/videos/202008/01/338337051/720P_4000K_338337051.mp4/seg-1.ts
// manifest: /hls/videos/202008/01/338337051/720P_4000K_338337051.mp4/master.m3u8
const year = pathParts[hlsIdx + 2]; // e.g. 2020
const subDir = pathParts[hlsIdx + 3]; // e.g. 01
const videoId = pathParts[hlsIdx + 4]; // e.g. 338337051
const variant = pathParts[hlsIdx + 5]; // e.g. 720P_4000K_338337051.mp4
// Extract auth params from segment query string — different CDN variants use different keys:
// ev-h/validfrom/validto/hash vs hv-h/h/e/f
const authParts = [];
for (const [key, val] of urlObj.searchParams) {
if (['h', 'e', 'f', 'validfrom', 'validto', 'hash'].includes(key)) {
authParts.push(`${key}=${val}`);
}
}
const authStr = authParts.length > 0 ? '?' + authParts.join('&') : '';
// Build manifest URL: include hls prefix AND variant directory
const manifestUrl = `${urlObj.protocol}//${urlObj.host}/${pathParts[hlsIdx]}/${pathParts[hlsIdx + 1]}/${year}/${subDir}/${videoId}/${variant}/master.m3u8${authStr}`;
// Need a directory to attach the manifest to (skip flat single-file paths).
if (pathParts.length < 3) continue;
pathParts.pop(); // drop the segment filename, keep its directory
const dir = pathParts.join('/');
// Carry the raw query (auth token) over unchanged — never re-encode it.
const q = m.url.indexOf('?');
const rawQuery = q === -1 ? '' : m.url.slice(q);
const manifestUrl = `${urlObj.protocol}//${urlObj.host}/${dir}/master.m3u8${rawQuery}`;
if (!seen.has(manifestUrl)) {
seen.add(manifestUrl);
reconstructed.push({ url: manifestUrl });
@@ -905,24 +867,26 @@ function filterManifests(manifests) {
}
/**
* Validate that a manifest URL uses a real phncdn.com path structure.
* Rejects fake paths like /videos/{id}/playlist.m3u8 — real manifests use
* /hls/videos/{year}/{subdir}/{videoId}/master.m3u8 or similar /hls/ paths.
* Validate that a manifest URL is well-formed and generic (CDN-agnostic).
* Rejects malformed paths; a manifest-like URL must live in a directory (have a
* path separator), which filters out obviously-broken single-segment paths.
*/
function isValidManifestUrl(url) {
if (!url || typeof url !== 'string') return false;
// Real phncdn HLS manifest: must contain /hls/videos/ with sufficient path depth
const hlsIdx = url.indexOf('/hls/videos/');
if (hlsIdx === -1) {
// Not phncdn — could be a different CDN, allow it
if (!url.includes('phncdn') && !url.includes('pornhubcdn')) return true;
// phncdn without /hls/ prefix is invalid for manifests
let urlObj;
try {
urlObj = new URL(url);
} catch {
return false;
}
// Check there are at least {year}/{subdir}/{videoId} after /hls/videos/
const after = url.substring(hlsIdx + '/hls/videos/'.length);
if (after.indexOf('/') === -1) return false; // need at least one more segment
return true;
const path = urlObj.pathname.toLowerCase();
const isManifestLike = path.includes('.m3u8') || path.includes('.hlsvod') ||
(path.includes('/playlist') && !path.endsWith('.ts')) ||
(path.includes('/master') && path.includes('.m3u'));
// Not a manifest path — allow it (it may be a direct media source, not HLS).
if (!isManifestLike) return true;
// A manifest path must sit in a directory, not be a bare top-level file.
return path.includes('/');
}
/**
@@ -941,7 +905,7 @@ function makeVideoEntry(video, tabTitle, posterFromContent) {
mediaType: video.mediaType || 'video',
};
if (video.hlsManifest) {
// Reject fake phncdn manifest paths before storing
// Reject fake/invalid manifest paths before storing
if (!isValidManifestUrl(video.hlsManifest)) {
console.warn('[goon] Rejecting fake manifest URL:', video.hlsManifest.substring(0, 120));
} else {
@@ -1004,28 +968,28 @@ async function scanVideos(tabsToScan) {
}
await logToPage(`step1.5 (webRequest): found ${totalWebRequestManifests} manifests via network interception`);
// Step 1.6: Strategy 8 — Query phncdn.com requests and reconstruct manifest URLs.
// Step 1.6: Strategy 8 — Query captured video requests and reconstruct manifest URLs.
// When the player uses in-memory dynamic HLS (zero .m3u8 network requests), we can
// still detect it by recognizing segment URL patterns from phncdn.com and deriving
// the parent manifest URL: /hls/videos/{id}/master.m3u8
const phncdnPromises = tabsToScan.map(t => queryPhncdnRequests(t.id));
const phncdnResults = await Promise.all(phncdnPromises);
let totalPhncdnManifests = 0;
// still detect it by recognizing segment URL patterns and deriving the parent
// manifest URL from the segment's directory.
const videoRequestPromises = tabsToScan.map(t => queryVideoRequests(t.id));
const videoRequestResults = await Promise.all(videoRequestPromises);
let totalReconstructedManifests = 0;
for (let i = 0; i < tabsToScan.length; i++) {
const reconstructed = phncdnResults[i]?.reconstructedManifests || [];
const reconstructed = videoRequestResults[i]?.reconstructedManifests || [];
if (reconstructed.length > 0) {
log('scanVideos phncdn: tab', tabsToScan[i].id, 'found', reconstructed.length, 'reconstructed manifests from segment URLs');
log('scanVideos strategy8: tab', tabsToScan[i].id, 'found', reconstructed.length, 'reconstructed manifests from segment URLs');
}
totalPhncdnManifests += reconstructed.length;
totalReconstructedManifests += reconstructed.length;
const existing = tabManifestMap.get(tabsToScan[i].id) || [];
for (const url of reconstructed) {
if (!existing.some(m => m.url === url)) {
existing.push({ url, player: 'phncdn_reconstructed' });
existing.push({ url, player: 'hls_reconstructed' });
}
}
tabManifestMap.set(tabsToScan[i].id, existing);
}
await logToPage(`step1.6 (phncdn): found ${totalPhncdnManifests} reconstructed manifests from segment URLs`);
await logToPage(`step1.6 (strategy8): found ${totalReconstructedManifests} reconstructed manifests from segment URLs`);
// Step 2: Scrape video elements (all frames) AND query content scripts (in parallel)
const scrapePromises = tabsToScan.map(t =>
+83 -48
View File
@@ -19,10 +19,10 @@
* overlays and an aggregate status bar.
*/
// HLS is vendored locally to avoid CSP blocks on sites like Pornhub that
// restrict script-src to 'self'. The hls.min.js bundle is built by Vite
// and exposed via chrome.runtime.getURL() so it loads from the extension
// origin, bypassing page CSP entirely.
// HLS is vendored locally to avoid CSP blocks on sites that restrict
// script-src to 'self'. The hls.js bundle is copied (not minified) so it
// loads from the extension origin via chrome.runtime.getURL(), bypassing
// page CSP entirely.
/**
* Grid-optimized hls.js configuration.
@@ -55,7 +55,8 @@ const panelsEl = document.getElementById('panels');
/** Track all Hls instances so we can destroy them on unload. */
/**
* Custom HLS loader that proxies phncdn.com URLs through the service worker
* Custom HLS loader that proxies URLs whose host blocks extension-origin
* requests (via a learned proxy-host set) through the service worker
* (bypassing CORS/Referer restrictions) and fetches everything else natively.
*
* hls.js creates one loader instance per request via `new HlsLoader(hls)`, then
@@ -135,7 +136,7 @@ const panelsEl = document.getElementById('panels');
stats.loading.start = trequest;
const isManifest = /\.m3u8($|\?)/i.test(url || '');
const needProxy = (url || '').includes('phncdn') || (url || '').includes('pornhubcdn');
const needProxy = needsProxy(url);
// hls.js loader callback contract (verified against the bundled loader):
// onSuccess(response, stats, context, networkDetails)
@@ -177,7 +178,7 @@ const panelsEl = document.getElementById('panels');
// Route through the service worker to bypass the CDN's CORS/Referer
// restrictions. The SW adds the required Referer and returns base64.
console.log('[goon-viewer] Proxying via SW:', (url || '').substring(0, 120));
chrome.runtime.sendMessage({ type: 'GOON_PROXY_FETCH', url }, (resp) => {
chrome.runtime.sendMessage({ type: 'GOON_PROXY_FETCH', url, referer: originForUrl(url) }, (resp) => {
if (self._aborted) return;
const lastErr = chrome.runtime.lastError;
if (lastErr || !resp || !resp.ok) {
@@ -233,22 +234,14 @@ const panelsEl = document.getElementById('panels');
HlsLoader.prototype.destroy = function () { this.abort(); };
HlsLoader.canSupportLoader = function () { return true; };
// === CORS diagnostics — check if phncdn.com allows extension-origin requests ===
(async function checkCors() {
try {
const resp = await fetch('https://phncdn.com/images/favicon.ico', { method: 'HEAD', mode: 'cors' });
console.log('[goon-viewer] CORS check phncdn.com:', resp.ok ? 'ALLOWED (status ' + resp.status + ')' : 'BLOCKED');
} catch(e) {
console.warn('[goon-viewer] CORS check phncdn.com: BLOCKED —', e && e.message ? e.message : e);
}
})();
// === HLS segment proxy helper ===
// Proxies a video URL through the service worker (no CORS restrictions).
// === Service-worker proxy helper (CDN-agnostic) ===
// Proxies a video URL through the service worker (no CORS restrictions). The
// SW forces the correct provider-origin Referer for the host (captured by the
// background worker), so a referer-protecting CDN accepts the request.
// Returns an ArrayBuffer of the response content.
async function proxyFetch(url) {
async function proxyFetch(url, referer) {
try {
const resp = await chrome.runtime.sendMessage({ type: 'GOON_PROXY_FETCH', url });
const resp = await chrome.runtime.sendMessage({ type: 'GOON_PROXY_FETCH', url, referer });
if (resp && resp.data && resp.ok) {
// Decode base64 → ArrayBuffer
const binary = atob(resp.data);
@@ -265,9 +258,43 @@ async function proxyFetch(url) {
}
}
// === Check if any manifest URLs require proxying (phncdn.com / cdn) ===
// CDN hosts that block extension-origin requests are learned by a CORS probe
// at viewer startup (hosts that fail the probe are recorded), then stored in
// chrome.storage.local. The proxy is used only for those hosts, so we never
// hardcode a particular CDN.
const PROXY_HOSTS_KEY = 'goon_proxy_hosts';
const proxyHosts = new Set();
(async () => {
try {
const stored = await chrome.storage.local.get(PROXY_HOSTS_KEY);
const hosts = stored[PROXY_HOSTS_KEY];
if (Array.isArray(hosts)) for (const h of hosts) proxyHosts.add(String(h).toLowerCase());
} catch { /* ignore */ }
})();
// Origin for a URL's host — used as the Referer to request when a proxy fetch
// is made for that host (the SW also captures the live referer per host).
function originForUrl(url) {
if (!url) return '';
try { return new URL(url).origin + '/'; } catch { return ''; }
}
// Whether a given video URL should be proxied: its host is a known
// referer-protected CDN host.
function needsProxy(url) {
if (!url || typeof url !== 'string') return false;
const host = hostOfUrl(url);
return host ? proxyHosts.has(host) : false;
}
// host of a URL (lowercased); '' when malformed.
function hostOfUrl(url) {
try { return new URL(url).host.toLowerCase(); } catch { return ''; }
}
// Whether any of the given URLs needs proxying.
function urlsNeedProxy(urls) {
return urls.some(u => u && typeof u === 'string' && (u.includes('phncdn') || u.includes('pornhubcdn')));
return urls.some(u => needsProxy(u));
}
/** Check whether fetching a URL from the extension page works (CORS test). */
@@ -750,9 +777,9 @@ function wireHlsEvents(hls, video, panel) {
renderPanelState(video, panel);
hls.destroy();
hlsInstances.delete(video);
// A fatal network error on a phncdn stream is almost always an expired
// auth token. The live source tab keeps rotating tokens, so pull a fresh
// manifest from it and retry — capped at a few attempts per panel so a
// A fatal network error on a token-protected stream is almost always an
// expired auth token. The live source tab keeps rotating tokens, so pull a
// fresh manifest from it and retry — capped at a few attempts per panel so a
// tab with no live source doesn't loop forever.
if ((video.dataset.hlsRescans || '0') | 0 < 3) {
video.dataset.hlsRescans = ((video.dataset.hlsRescans || '0') | 0) + 1;
@@ -930,9 +957,9 @@ function playHls(video, manifestUrl, panel) {
return;
}
// Check whether this manifest URL needs proxying (phncdn.com without CORS headers
// blocks extension-origin requests from the viewer page).
const needProxy = manifestUrl.includes('phncdn') || manifestUrl.includes('pornhubcdn');
// Check whether this manifest URL needs proxying (a referer-protected host
// without CORS headers blocks extension-origin requests from the viewer page).
const needProxy = needsProxy(manifestUrl);
if (needProxy) {
console.log('[goon-viewer] Manifest needs proxying via service worker');
}
@@ -978,7 +1005,7 @@ function playHls(video, manifestUrl, panel) {
console.log(`[goon-viewer] Loading HLS manifest:`, manifestUrl.substring(0, 200));
// Remember the manifest actually loaded so a later auto-rescan can retry from
// the freshest token on the same video (extractVideoId keys off this).
// the freshest token on the same video (the service worker keys off the path).
video.dataset.hlsManifest = manifestUrl;
hls.loadSource(manifestUrl);
@@ -1018,23 +1045,23 @@ function loadHlsJs() {
}
/* ======================================================================== */
/* Fresh-token resolution — replace expired/revoked phncdn URLs */
/* Fresh-token resolution — replace expired/revoked token URLs */
/* ======================================================================== */
/**
* Ask the service worker for the freshest live phncdn manifest for the video
* encoded in `storedUrl`. The live source tab keeps rotating short-lived
* phncdn tokens (a stored one may already be 410 Gone), so the freshest
* captured manifest — identified by matching the videoId in the path — is the
* one that will actually validate. Resolves to the new URL, or null when the
* tab captured nothing (or the caller can't reach the SW).
* Ask the service worker for the freshest live manifest for the video encoded
* in `storedUrl`. The live source tab keeps rotating short-lived auth tokens
* (a stored one may already be 410 Gone), so the freshest captured manifest —
* identified by matching the video's group key in the path — is the one that
* will actually validate. Resolves to the new URL, or null when the tab
* captured nothing (or the caller can't reach the SW).
*/
async function resolveFreshManifest(storedUrl) {
if (!storedUrl || !storedUrl.includes('phncdn')) return null;
if (!storedUrl || !needsProxy(storedUrl)) return null;
try {
const resp = await chrome.runtime.sendMessage({ type: 'GOON_RESOLVE_MANIFEST', url: storedUrl });
if (resp && resp.ok && resp.changed && resp.fresh) {
console.log('[goon-viewer] resolved fresh manifest for', (resp.videoId || '?'),
console.log('[goon-viewer] resolved fresh manifest for', (resp.groupKey || '?'),
'→', (resp.fresh || '').substring(0, 100));
return resp.fresh;
}
@@ -1154,16 +1181,24 @@ async function init() {
});
}
// Test CORS on all video URLs
// Probe CORS on each video URL. Hosts that block extension-origin
// requests are learned as referer-protected and persisted so the viewer
// routes them through the service-worker proxy.
const urlsToTest = videoUrls.map(v => v.src || v.hlsManifest || 'none').filter(u => u !== 'none' && typeof u === 'string');
const blockedHosts = new Set();
for (const url of [...new Set(urlsToTest)]) {
const corsOk = await corsCheck(url);
if (!corsOk) blockedHosts.add(hostOfUrl(url));
console.log('[goon-viewer] CORS', corsOk ? 'OK' : 'BLOCKED:', url.substring(0, 120));
}
if (blockedHosts.size > 0) {
for (const h of blockedHosts) if (h) proxyHosts.add(h);
try { await chrome.storage.local.set({ [PROXY_HOSTS_KEY]: [...proxyHosts] }); } catch { /* ignore */ }
}
// Check if any URLs point to phncdn.com (proxy will be needed if CORS blocked)
const needsProxy = urlsToTest.some(u => u.includes('phncdn') || u.includes('pornhubcdn'));
console.log('[goon-viewer] Proxy required:', needsProxy);
// Report whether any URL needs proxying (referer-protected host).
const anyNeedsProxy = urlsNeedProxy(urlsToTest);
console.log('[goon-viewer] Proxy required:', anyNeedsProxy);
} else {
console.warn('[goon-viewer] No video entries in storage for ID:', id, '— data may have been cleared or never saved');
}
@@ -1194,11 +1229,11 @@ async function init() {
}
return;
}
// Before playback, swap each stored phncdn manifest for the freshest live
// one the source tab has captured (a stored token may already be 410
// Gone). Non-phncdn manifests are left untouched.
for (const { video, manifest, panel } of hlsEntries) {
if (manifest.includes('phncdn')) {
// Before playback, swap each referer-protected manifest for the freshest
// live one the source tab has captured (a stored token may already be 410
// Gone). Non-protected manifests are left untouched.
for (const { video, manifest } of hlsEntries) {
if (needsProxy(manifest)) {
const fresh = await resolveFreshManifest(manifest);
if (fresh) video.dataset.hlsManifest = fresh;
}