Skip to content

Add CompressionStream and DecompressionStream polyfills - #211

Open
matthargett wants to merge 8 commits into
BabylonJS:mainfrom
rebeckerspecialties:compression-stream-polyfill
Open

matthargett wants to merge 8 commits into
BabylonJS:mainfrom
rebeckerspecialties:compression-stream-polyfill

Conversation

@matthargett

@matthargett matthargett commented Jul 22, 2026

Copy link
Copy Markdown

Summary

  • add optional CompressionStream and DecompressionStream polyfills for gzip, deflate, and deflate-raw
  • preserve host-provided constructors and initialize WHATWG Streams as the only polyfill dependency
  • use the platform/existing zlib target when available, with a pinned zlib 1.3.1 fallback

Depends on #208.

Ownership

Input BufferSource views are borrowed only during a synchronous zlib call. Output is buffered before any enqueue callback can run JavaScript, then copied once into exact-size JS-owned Uint8Arrays. Each active codec reuses one 64 KiB native scratch buffer and releases zlib/scratch storage immediately on completion or error.

Coverage

Focused tests cover the WPT compression suite, including constructor conversion, BufferSource variants and offsets, split/empty chunks, large flush output, corrupt/truncated input, trailing data, and Uint8Array output. They also exercise the input-invalidation safeguard documented by Chromium's transformer, Firefox's output-before-extra-input-error ordering, and WebKit's BufferSource validation path.

Validated with:

  • JavaScriptCore ASan/UBSan: 229 JS cases plus native tests
  • QuickJS Release: 229 JS cases plus native tests
  • JavaScriptCore TSan: 229 JS cases plus native tests

Copilot AI review requested due to automatic review settings July 22, 2026 06:13

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Vendor the ES5 web-streams-polyfill 4.3.0 ponyfill and expose an idempotent Streams initializer that preserves constructors supplied by the selected JavaScript engine.

Cover readable, writable, transform, BYOB, error, tee, subclassing, and host-constructor behavior with focused ports from WPT plus Firefox and Chromium regression tests. Validate the implementation on JavaScriptCore under ASan/UBSan and QuickJS Release.
Add optional CompressionStream and DecompressionStream polyfills for gzip, deflate, and raw deflate on top of WHATWG Streams. Reuse one native output buffer per active codec, borrow input views only synchronously, and defer JavaScript enqueue callbacks until zlib has finished consuming each input.

Cover constructor and BufferSource behavior, split and empty chunks, large flushes, corrupt/truncated/trailing input, reentrant input mutation, and repeated stream teardown with focused WPT and browser-engine regression tests. Preserve host constructors and use platform zlib where available with a pinned fallback.
Replace a partial or null host Streams surface as a complete constructor suite so stream products retain compatible instanceof relationships. Preserve a complete suite on repeated initialization.\n\nHarden the native initialization test so N-API failures complete the test promise instead of hanging, and cover partial host replacement plus null handling and cross-constructor compatibility.
…nto the Android test host

MSVC caps a single string literal at 16,380 bytes (C2026) and a concatenated one at
65,535; the 71 KB bundle was emitted as two 60,000/11,188-byte raw strings, so every
Windows and UWP job failed at "Build Solution". CMake now emits consecutive parts of
at most 16,000 bytes, abutting with no separator (the split stays byte-transparent),
and a variadic consteval Join reassembles them into the same std::array as before.

The desktop UnitTests target links Streams for the Shared.cpp coverage but the
Android UnitTestsJNI host did not, so the Android build failed on the include.
@matthargett
matthargett force-pushed the compression-stream-polyfill branch from 3d5f998 to 1e7557b Compare September 13, 2026 07:58
The JSI backend implements no C napi_* entry points, so the raw napi_throw_type_error
failed to compile there (C3861). Napi::TypeError::ThrowAsJavaScriptException sets the
pending exception without throwing C++, preserving the reentrancy rationale, and exists
on every backend.

On Apple, find_library(z) captured the device SDK's libz.tbd at configure time; the
simulator link rejected it ("missing required architecture x86_64"). Linking "z" by
name lets the linker resolve it against the active SDK.
…allback runs

The codec collected its output chunks as Napi::Uint8Array values in a
std::vector while zlib kept producing more. Between two chunks the next
Uint8Array allocation can trigger a collection, and the JavaScriptCore
backend roots nothing that is not on the C stack or protected (its
handle scopes are stubs), so an earlier pending chunk could be reclaimed
and its storage reused before enqueue ran. The 256 KiB reentrancy test
then failed with "incorrect header check" on macOS and Android CI, and
deterministically under JSC_collectContinuously=1.

Keep the staged output as bytes and create each Uint8Array right before
it is enqueued, where the fresh value lives on the stack for the call.

(cherry picked from commit c6f1f7b3e29fea7921aee1431dd8725c6e8c2a41)
@matthargett

Copy link
Copy Markdown
Author

Pushed c3893a4: the codec staged its output chunks as Napi::Uint8Array values in a std::vector while zlib produced more. The JavaScriptCore backend's handle scopes are stubs and it roots only what is on the C stack or protected, so a collection triggered by allocating the next chunk could reclaim an earlier pending one — the 256 KiB reentrancy test then failed with "incorrect header check" on macOS and Android CI, and deterministically under JSC_collectContinuously=1. The output is now staged as bytes and each Uint8Array is created right before it is enqueued (3/3 green under continuous GC where the old code failed 3/3).

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.

2 participants