Version 0.4.0 makes JS code that breaks at load time on Safari 14 #28
Comments
|
cc @mfish33 This is an interesting one, and a bit unfortunate. I'm surprised those are referenced at top-level scope, I guess we need some way to retrieve them lazily instead. |
|
@RReverser I think this is upstream from us. In the generated code by wasm bindgen these three lines are the culprit. const u32CvtShim = new Uint32Array(2);
const int64CvtShim = new BigInt64Array(u32CvtShim.buffer);
const uint64CvtShim = new BigUint64Array(u32CvtShim.buffer);Defined in: Further, it seems that this issue does not exactly have to do with Bigint types rather having rust bindings that receive u64/i64's as arguments or JS bindings that return u64/i64's |
Right I see, and we introduced those for our |
Previously, they were passed as a pair of `i32`s; this changes them to be passed as a single `i64`, which is directly converted to a bigint on the JS end. I think they were previously passed as a pair because `wasm-bindgen`'s support for 64-bit integers predated the WebAssembly bigint integration that translates `i64`s to bigints. However, that feature has been around for quite a while now, so I think it should be fine to use. I also bumped the schema version - although the schema itself hasn't changed, the ABI has, so using an older version of the CLI with this version of the `wasm-bindgen` crate or vice versa won't work and I want the version-mismatch warning to show up. Fixes RReverser/serde-wasm-bindgen#28. This doesn't rely on a global `BigInt64Array` like the previous `i32`-pair version, which means that code using 64-bit integers will no longer fail at load time in browsers without bigint support.
Previously, they were passed as a pair of `i32`s; this changes them to be passed as a single `i64`, which is directly converted to a bigint on the JS end. I think they were previously passed as a pair because `wasm-bindgen`'s support for 64-bit integers predated the WebAssembly bigint integration that translates `i64`s to bigints. However, that feature has been around for quite a while now, so I think it should be fine to use. I also bumped the schema version - although the schema itself hasn't changed, the ABI has, so using an older version of the CLI with this version of the `wasm-bindgen` crate or vice versa won't work and I want the version-mismatch warning to show up. Fixes RReverser/serde-wasm-bindgen#28. This doesn't rely on a global `BigInt64Array` like the previous `i32`-pair version, which means that code using 64-bit integers will no longer fail at load time in browsers without bigint support.
|
This should be fixed as of rustwasm/wasm-bindgen#3037. |
|
Great! |
We just had to swiftly revert our dependency on
serde-wasm-bindgenback to 0.3.1, as the introduction of BigInt support makesBigUint64ArrayandBigInt64Arraybe referenced at module scope in the*_bg.jswrapper, causing the module to fail to load in Safari 14 and earlier. Safari does not have these types until version 15.0 (released last Sep 20th, so there's still lots of Safari 14 out there).This can break the whole web application (depending on one's bundling, I guess), even one that makes no use of this new BigInt support, in those browser versions.
So version 0.4 (and the README, if this stays as-is) should really carry a nice big warning about this effect on browser support.
The text was updated successfully, but these errors were encountered: