refactor: decouple from site-specific CDN references #5
No files matched your search
@@ -8,8 +8,7 @@
|
|||||||
"tabs",
|
"tabs",
|
||||||
"scripting",
|
"scripting",
|
||||||
"webRequest",
|
"webRequest",
|
||||||
"declarativeNetRequest",
|
"declarativeNetRequest"
|
||||||
"extraHeaders"
|
|
||||||
],
|
],
|
||||||
"host_permissions": [
|
"host_permissions": [
|
||||||
"<all_urls>"
|
"<all_urls>"
|
||||||
|
|||||||
@@ -7,6 +7,9 @@
|
|||||||
|
|
|||||||
"": {
|
"": {
|
||||||
"name": "vidplex",
|
"name": "vidplex",
|
||||||
"version": "0.1.0",
|
"version": "0.1.0",
|
||||||
|
"dependencies": {
|
||||||
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
"@rollup/rollup-darwin-arm64": "^4.63.1"
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
},
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
"devDependencies": {
|
"devDependencies": {
|
||||||
"ajv": "^8.17.1",
|
"ajv": "^8.17.1",
|
||||||
"ajv-formats": "^3.0.1",
|
"ajv-formats": "^3.0.1",
|
||||||
@@ -1335,15 +1338,13 @@
|
|||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
]
|
]
|
||||||
},
|
},
|
||||||
"node_modules/@rollup/rollup-darwin-arm64": {
|
"node_modules/@rollup/rollup-darwin-arm64": {
|
||||||
"version": "4.60.4",
|
"version": "4.63.1",
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
"resolved": "https://registry.npmjs.org/@rollup/rollup-darwin-arm64/-/rollup-darwin-arm64-4.60.4.tgz",
|
"resolved": "https://registry.npmjs.org/@rollup/rollup-darwin-arm64/-/rollup-darwin-arm64-4.63.1.tgz",
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
"integrity": "sha512-tua0TaJxMOB1R0V0RS1jFZ/RpURFDJIOR2A6jWwQeawuFyS4gBW+rntLRaQd0EQ4bd6Vp44Z2rXW+YYDBsj6IA==",
|
"integrity": "sha512-FQNqd1lRy/0QhDk3xeRIkSBiCpXCiDnZO3YLVdcDKN1UBiKToNftCzcXYNLshmPDUMlu2TdeS8tGcsU6f3YF1Q==",
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
"cpu": [
|
"cpu": [
|
||||||
"arm64"
|
"arm64"
|
||||||
],
|
],
|
||||||
"dev": true,
|
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
"license": "MIT",
|
"license": "MIT",
|
||||||
"optional": true,
|
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
"os": [
|
"os": [
|
||||||
"darwin"
|
"darwin"
|
||||||
]
|
]
|
||||||
@@ -3422,6 +3423,20 @@
|
|||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
"fsevents": "~2.3.2"
|
"fsevents": "~2.3.2"
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
|
"node_modules/rollup/node_modules/@rollup/rollup-darwin-arm64": {
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
"version": "4.60.4",
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
"resolved": "https://registry.npmjs.org/@rollup/rollup-darwin-arm64/-/rollup-darwin-arm64-4.60.4.tgz",
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
"integrity": "sha512-tua0TaJxMOB1R0V0RS1jFZ/RpURFDJIOR2A6jWwQeawuFyS4gBW+rntLRaQd0EQ4bd6Vp44Z2rXW+YYDBsj6IA==",
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
"cpu": [
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
"arm64"
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
],
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
"dev": true,
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
"license": "MIT",
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
"optional": true,
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
"os": [
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
"darwin"
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
]
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
|
},
|
||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
"node_modules/rollup/node_modules/@types/estree": {
|
"node_modules/rollup/node_modules/@types/estree": {
|
||||||
"version": "1.0.8",
|
"version": "1.0.8",
|
||||||
"resolved": "https://registry.npmjs.org/@types/estree/-/estree-1.0.8.tgz",
|
"resolved": "https://registry.npmjs.org/@types/estree/-/estree-1.0.8.tgz",
|
||||||
|
|||||||
|
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
robot
commented
[FYI] F4 [FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
**Suggested fix:** Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
|
|||||||
@@ -315,7 +315,8 @@ function originFromHost(host) {
|
|||||||
|
robot
commented
Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal. Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
robot
commented
Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue). Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
robot
commented
Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal. Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
robot
commented
Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue). Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
robot
commented
[SHOULD-FIX] F2 [SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
**Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
robot
commented
[SHOULD-FIX] F2 [SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
**Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers 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
|
// Read the `Referer` request header (the browser may title-case it; the
|
||||||
// `extraHeaders` option exposes it to MV3 onBeforeSendHeaders).
|
// (onBeforeSendHeaders cannot read request headers in MV3 without a blocking API,
|
||||||
|
robot
commented
Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal. Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
robot
commented
Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue). Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
robot
commented
[SHOULD-FIX] F2 [SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
**Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
robot
commented
Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal. Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
robot
commented
Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue). Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
robot
commented
[SHOULD-FIX] F2 [SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
**Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
|
|||||||
|
// so we fall back to the page origin for hosts that send no referer).
|
||||||
|
robot
commented
Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal. Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
robot
commented
Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue). Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
robot
commented
[SHOULD-FIX] F2 [SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
**Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers 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) {
|
function readReferer(headers) {
|
||||||
if (!Array.isArray(headers)) return '';
|
if (!Array.isArray(headers)) return '';
|
||||||
for (const h of headers) {
|
for (const h of headers) {
|
||||||
@@ -385,7 +386,7 @@ chrome.webRequest.onBeforeSendHeaders.addListener(
|
|||||||
|
robot
commented
Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal. Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
robot
commented
Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue). Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
robot
commented
Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal. Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
robot
commented
Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue). Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
robot
commented
[SHOULD-FIX] F2 [SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
**Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
robot
commented
[SHOULD-FIX] F2 [SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
**Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers 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));
|
await persistReferer(host, originFromHost(host));
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
{ urls: ['<all_urls>'], extraHeaders: ['Referer'] }
|
{ urls: ['<all_urls>'] }
|
||||||
|
robot
commented
Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal. Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
robot
commented
Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue). Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
robot
commented
[SHOULD-FIX] F2 [SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
**Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
robot
commented
Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal. Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
robot
commented
Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue). Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
robot
commented
[SHOULD-FIX] F2 [SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
**Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers 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
|
// Install (idempotently) a DNR rule that sets the captured referer for a given
|
||||||
|
|||||||
|
robot
commented
Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal. Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
robot
commented
Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue). Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
robot
commented
Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal. Blocking: 'goon_referers' is a host-keyed GLOBAL store meant to outlive its capture tab (see the docstring just above and the PR body: "persist it per CDN host ... even after this capture tab closes"). Adding it to the per-tab onRemoved cleanup means closing ANY tab wipes referers captured by other still-open source tabs, so the next proxy fetch for those hosts loses its referer and 412s. Remove 'goon_referers' from this array (keep the per-tab vr_requests_ / wr_manifests_ keys). If you want cleanup, key it per host with an expiry instead of on every tab removal.
robot
commented
Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue). Concurrent-proxy race: REFERER_RULE_ID is a single shared id and the idempotency check + updateSessionRules({removeRuleIds, addRules}) are not atomic. Two hosts proxied in parallel (common in the multi-panel grid) can interleave so the live rule ends up host B's while refererRuleInstalled records host A as installed -> host A's fetches get host B's referer -> 412. Now that the rule is per-host, use a distinct rule id per host (or add all hosts' rules in one updateSessionRules call) and make the install+record atomic (per-host async lock / queue).
robot
commented
[SHOULD-FIX] F2 [SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
**Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
robot
commented
[SHOULD-FIX] F2 [SHOULD-FIX] F2
Documentation/behavior mismatch. The PR body, commit 66c6218 message, and the code comments at :311 (:311 'via chrome.webRequest.onBeforeSendHeaders, which sees the request headers') describe an onBeforeSendHeaders + extraHeaders header-reading capture. The actual code uses onBeforeRequest (cannot read request headers) and derives the referer from the source TAB's URL instead (chrome.tabs.get). The `extraHeaders` permission is not declared in manifest.json (permissions: storage, tabs, scripting, webRequest, declarativeNetRequest). The commit message for :245-248 ('extraInfoSpec ... is rejected by some Chromium builds and fails the whole service worker') explains why, but the PR body / high-level comments were never updated to match, so a reviewer is misled about the mechanism.
**Suggested fix:** Reword the PR body and the :311/:308-314 comments to say the referer is derived from the source tab URL (via onBeforeRequest + chrome.tabs.get) rather than 'read from request headers via onBeforeSendHeaders'. The actual mechanism is sound and arguably safer than reading real headers; the mismatch is a documentation issue, not a correctness one.
|
|||||||
[FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
Suggested fix: Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.
[FYI] F4
The PR also churns package-lock.json: it adds a top-level 'dependencies': {@rollup/rollup-darwin-arm64:'^4.60.4'} to the root '' entry and clears the 'dev':true/'optional':true flags on the darwin-arm64 package, while package.json now has an empty 'dependencies': {}. This looks like an npm-install side effect on the author's ARM-Mac that leaked in, unrelated to the decoupling refactor. Build still passes locally (copy-hlds.mjs copies the hls bundle), so it is not a functional break, but the lock churn is noise and a platform-specific optional dep should not be promoted to a hard dependency.
Suggested fix: Re-generate package-lock.json on a clean install and avoid forcing @rollup/rollup-darwin-arm64 into 'dependencies'; keep it as the platform-optional dev dep it already is, or drop it entirely.