Skip to content

fix(extension): binary direct fallback no longer decodes the body to text - #54

Merged
wolfgang-aura merged 1 commit into
mainfrom
fix/direct-fallback-binary-text
Oct 5, 2026
Merged

wolfgang-aura merged 1 commit into
mainfrom
fix/direct-fallback-binary-text

Conversation

@wolfgang-aura

Copy link
Copy Markdown
Owner

Fixes #53.

A binary response over ~48 MB passes Chrome's 64 MiB message limit as base64, so compat.js falls back to directHttpRequest. That function always decoded the body into responseText, which for a 52 MB video is a ~52-million-character string nothing reads. It now returns only the ArrayBuffer for responseType: 'arraybuffer', the same contract as the proxy path since #13. Both userscript readers of responseText request text.

  • Regression assert in test/extension.test.mjs (failed before the fix).
  • Live: v1.6.7 + this change loaded into Brave 154 via the chrome-devtools MCP. A 51,986,124-byte MP4 now arrives through the fallback as an ArrayBuffer of that size with no responseText. Before the change the same call returned responseText set.

🤖 Generated with Claude Code

…text

Videos over ~48 MB pass Chrome's message limit as base64, so they take
compat.js's direct fallback. That path always set responseText, holding a
decoded copy of the whole file that nothing reads. It now matches the proxy
path: a binary reply carries only the ArrayBuffer.

Fixes #53

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@wolfgang-aura
wolfgang-aura merged commit e81a1c0 into main Oct 5, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Extension direct fallback decodes binary media into an unused text copy

1 participant