We’ve had a couple users get this error when trying to load our page. Governance.origyn.network. In this instance, it was on android chrome. Refreshing it seems to make it go away, but we see it enough times now that we thought we should ask.
3 Likes
I cannot reproduce it myself on my devices (Macbook and iPhone). I’ll forwarded your question to the team.
Had several complaints as well.
This one is from Brave but is the same for Chrome every few minutes one of this pops up. This one in particular is for the NNS. Reproduced on Android 12 , 12.1 and 13 regardless of hardware spec all with latest security updates.
Thanks for the report. Interesting it’s another stacktrace. In OP message it’s a Wasm issue there you seem to have a network issue 
.
Just noticed both were taken at minute :55 
Note that the error actually happens in JS-side code, when some JS tries to instantiate/link a Wasm module. The Wasm module expects a function import from JS, but the JS glue code passes something that is not a function. Often that happens when the actual value is a JS undefined, e.g., due to some latent type error in the JS code or some other unhandled error.
Something with time indeed, this error was also just shared on Discord
Simple refresh solves it so it’s not a problem just annoying. Also only happens when used in a browser, if you choose to install / add to home screen and then launch from there, it works fine with no errors.
1 Like
Thanks for reporting this @skilesare. This wonderfully descriptive error message is shown for any exception thrown inside the WASM boundary so we don’t know what exactly is causing that, but we have a new service worker version currently being rolled out that enables better exception handling and this should show a more helpful message.
@ZackDS the error message you’ve posted looks like a connection issue with the boundary nodes. I’ll ping the relevant team.
@peterparker the issue you posted is caused by either a replica that’s running behind, or a device that’s ahead.
I’m confident that these are three independent issues. The original is on Saturday, ZackDS’s is from Thursday and peterparker’s is from Sunday.
3 Likes
Hey folks - apologies for the inconvenience. Like @NathanosDev these are likely different issues.
The issue pointed out by @skilesare is related to an upgrade to the service worker. After the new version of the service worker loads, it fails to load the WASM for response verification.
This can be fixed by simply refreshing the page which will require the service worker to reload and load the WASM properly.
This is not the first time we run into issues with the service worker loading the wasm after an upgrade, so to avoid future issues, we are going to be bundling the WASM into the service worker.
1 Like
I’m having the same issue. Redeployed the asset canister with v0.14.3 and still getting the error.
DecompressionStream is now used in the service worker to handle the different compressions (e.g. gzip, deflate).
Chrome has support since 2020, the issue is likely related that you are using a browser that is out-of-date, an update should fix it.
Firefox has added support for it since May, 2023 and Safari since March, 2023.
fyi @yangzijiang @curry
Chrome for Desktop has this available since version 80 (Released 2020-02-04).
Are you using mobile? if yes, then note that even while using Chrome on an iOS device, it is using safari as it’s engine, and Safari added support on iOS only for version 16.4 (Released 2023-03-27).
@Kepler Just a suggestion: it may be worth considering polyfilll such features when a user’s browser does not support it.
Asking everyone to upgrade to the latest technology is often unrealistic, because people often have their own reasons to keep (or be stuck with) their old devices/OSes/etc.
Given that service worker is such an essential piece, and will pretty much impact all sites on IC, it makes even more sense to be a bit conservative here.
The DecompressionStream was added with the goal of reducing the size of the service worker, which polyfills would not help since we would still maintain the bigger bundle size with it.
We are discussing the possibility of alternatives already though (e.g. polyfills) since we missed the fact that it was added only in Q1/2 2023 for Safari and Firefox respectively. Note that according to browser stats, 84.59% of global users have versions that support that API already, in terms of comparison this is 9.58% lower then supporting service workers themselves which is currently at 94.17%.
2 Likes
We will make a release today that will fix this issue for people with older browsers, sorry for the frustration!
2 Likes
Can we get an update when the fix is released 
Made my own thread to discuss this without seeing this one.
Have the most updated version of chrome & safari and still receiving:
“ Page failed to load.
ReferenceError: Can’t find variable: DecompressionStream”
Any insight?
Hi @Jamietier - we are rolling out another version of the service worker just now that doesn’t rely on the DecompressionStreams API which are only available in more recent versions of the safari.