Flutter web dart2wasm: enum conversion and detached heap views in rive_native

Start with the public reproduction linked in the issue and reproduce with flutter build web --wasm --profile --no-minify-wasm; compare against the dart2js build. The reported failures are in rive_native enum conversion and view-model path reads after WebAssembly memory growth. Review the linked two-commit correction and verify the enum values and both paths keep returning the expected values before and after heap growth.

Submission checklist

• I have confirmed the issue is present in the latest version of the rive Flutter package
• I have searched the documentation and forums and could not find an answer
• I have searched existing issues and this is not a duplicate

Description

Two Dart-to-JavaScript interop failures reproduce on Flutter 3.47.9 / Dart 3.13.7 in headless Chrome with both the latest published prerelease pair and the latest stable pair. The public reproduction and captures are included here. Thank you for taking a look.

Following the arrangement in #665, the suggested correction is offered on a copy of rive_native 0.2.0-dev.4 verbatim from pub.dev: branch, two-commit comparison, .patch. The same patch is included locally. A separate report on GPU canvas image views on the web, #669, uses the same copy.

Related reports: a comment on #628 describes the identical detached-buffer error, and #593 describes Wasm failures in the same view-model APIs, both without a root cause or a reproduction. This report adds two source causes, a public reproduction and a suggested correction.

With Flutter web compiled using --wasm, two independent interop failures occur in rive_native:

1. Reading the elements of file.enums fails a Dart string type check.
2. After Rive's WebAssembly memory grows, short view-model path lookups write through a detached typed-array view and keep failing on subsequent reads.

Expected: enum values are Dart strings ([Coin, Gem]), and the number and enum paths keep returning 1300 and Gem before and after memory growth.

Actual, with rive 0.15.0-dev.4 / rive_native 0.2.0-dev.4:

PASS before number(Coin/Item_Value): 1300.0
PASS before enumerator(Item_Selection/Item_Selection): Gem
FAIL before file.enums: Runtime type check failed (details omitted due to --omit-error-details)
PASS after large 9 number(Coin/Item_Value): 1300.0
FAIL after large 10 number(Coin/Item_Value): TypeError: Cannot perform DataView.prototype.setUint8 on a detached or out-of-bounds ArrayBuffer

The tenth retained large decode grows Rive's heap from 67,108,864 to 80,543,744 bytes and detaches its previous buffer. The path reads continue to fail after decodes 11 and 12 and on the final retry. The stable pair (rive 0.14.11 / rive_native 0.1.11) behaves the same way. Both published pairs pass all 30 reads when compiled with dart2js. With both suggested corrections, all 30 reads pass under both compilers, including after the same observed heap growth.

The existing report in #628 includes the identical detached-buffer error, and #593 describes potentially related Wasm API failures. This reproduction isolates two source causes; it does not establish whether those reports share a cause.

Reproduction steps / code

The standalone project, public fixtures, scripts and captures are at https://github.com/rydmike/rive_wasm_issue.

If preferred, the whole sample is also in the ZIP under "Upload your reproduction files / stack trace". The .riv files are repro/assets/rewards.riv and repro/assets/semantics.riv in it, so they are not uploaded again under "Source .riv / .rev file".

1. Use Flutter 3.47.9 stable / Dart 3.13.7. From repro/, run flutter pub get.
2. Run flutter build web --wasm --profile --no-minify-wasm.
3. From the repository root, run python3 tool/serve.py repro/build/web --port 8123.
4. Open http://127.0.0.1:8123 in Chrome. The app runs automatically and writes results to the page and console.
5. Compare a build using flutter build web --profile --no-wasm-dry-run.

The app decodes public rewards.riv, creates the default Rewards view-model instance and reads these values:

instance.number('Coin/Item_Value')!.value; // 1300
instance.enumerator('Item_Selection/Item_Selection')!.value; // Gem
for (final e in file.enums) {
  print(List<String>.of(e.values)); // Forces element access.
}

It retains 12 decodes of public semantics.riv, repeating both path reads after each decode and once more at the end. One large decode fits in the initial heap; retaining multiple decodes triggers growth through normal allocation. The capture harness observes WebAssembly.Memory.grow; it does not force growth or change the initial heap. The full matrix, the path-dependency instructions and the captures are in the repository README.

Upload your reproduction files / stack trace

rive_wasm_issue-repro.zip

Source .riv / .rev file

No response

Screenshots / video

fixed-wasm.png
newest-wasm.png

Rive Flutter package version

Latest published prereleases: rive 0.15.0-dev.4 / rive_native 0.2.0-dev.4. Latest stable: rive 0.14.11 / rive_native 0.1.11. Both pairs reproduce both failures with dart2wasm. Versions checked against pub.dev on 2026-11-08; the correction is based on rive_native 0.2.0-dev.4. The same failures and the same correction were first measured on 0.2.0-dev.3 with Flutter 3.47.7 on 2026-10-21.

Flutter version

Flutter 3.47.9 • channel stable • https://github.com/flutter/flutter.git
Framework • revision c197ca5199 (10 days ago) • 2026-10-29 10:10:20 -0400
Engine • hash 9e025265bef30b838c0c1b68cad19decf97048f2 (revision 89c39edfdf) (11 days ago) • 2026-10-27 19:51:20.000Z
Tools • Dart 3.13.7 • DevTools 2.60.0

Device

Desktop web, arm64 host; real headless Google Chrome 156.0.8078.81, controlled with puppeteer-core 25.15.0. Fresh browser process/profile for each capture, software WebGL enabled with --enable-unsafe-swiftshader.

OS version

macOS 27.0.1, build 26A434, arm64.

Additional context

rive_native does not offer a public repository for a pull request, so the suggested two-commit correction follows the packaging used in #665: a verbatim pub.dev baseline, one commit per source defect, and a downloadable patch.

• Verbatim baseline
• Correction branch
• Compare main...fix-wasm-interop-0.2.0-dev.4
• Download .patch
• Existing identical error in #628
• Potentially related view-model failures in #593

The archive SHA-256 is c617034971488a3acbfb1f42ec47e39e5e43e66fbf84c36b1d468e5ac4cb20f9, checked against pub.dev metadata. The change uses the existing interop helpers, adds no dependency and retains the disposed-pointer guard. Its performance cost was not measured. This reproduction covers decoding and data-binding reads; Rive rendering/animation, native platforms and other browsers were not tested.

We also verified the correction in our production app, a large Flutter web app, using the fix branch through a dependency override. A dart2wasm build deployed to our staging site (multi-threaded, cross-origin isolated) now loads and plays the large Rive files that failed with the detached ArrayBuffer error after smaller ones, with no interop errors in Chrome.