WebGL: "both async and sync fetching of the wasm failed". Build and runs works, fails when uploading

Unity Engine
1

Hello,
I tried to build the most simple WebGL application possible with Unity 2020.1 as I was having issue with uploading my game. I thought it was the game itself so I tried a very simple project.

One label showing “Test”

While build and run works flawlessly locally, I tried to upload it on my ftp and get a few errors.
“Both async and sync fetching of the wasm failed”

Then the loading is stuck at 90%
I have the same behavior in Firefox and Chrome.
See errors here:
www.awakendreamsprod.com

Hope you can help, thanks in advance!

1 Like
2

enabling Decompression fallback fixed my issue… Now I’m not sure it’s a good thing…
I have no experience with online application.
Should I do something else?
Thanks

3

I got the same issue where a simple application stopped at 90%.
Disabled the compression in Player settings - Publishing settings - Compression format and then it worked. At least in MS Edge.

4

I’m having the same issue as the original post. I have disabled compression and I still get the same error. Any other ideas?

3 Likes
5

yeah, same probleme here…

6

There is one bug where if you use “Filenames as hashes” together with a compressed build (gzip or brotli) then decompression will fail. Even with the new web.config or htaccess file.
This is due to the fact that when filenames are converted to hashes they lose their .data and .wasm extension in the naming.
Which brings me to my next point, they changed the extension a little bit. So mimetypes have to be changed accordingly.

If you’re running old configurations you’re going to require a new configuration.

So yeah quite some changes have been made to 2020.1 WebGL, including the Template it uses. Old custom templates will be broken as far as I know.

WebGL Mobile is no longer blocked by an unsupported message. But it is not the most performant either.
for Apple devices, Safari is only supporting WebGL 1.0 (unless experimental WebGL 2.0 is enabled. They never continued development because they are focussing on WebGPU instead)
for Android WebGL 2.0 can be used on Chrome / Firefox. But still, not super performant.
The hope is that in some time (1 or 2 yrs) WebGPU is fully developed and embraced by all browsers.

7

It worked for me.

I’m using Unity 2020, and since that has a compression bug, I had to turn off GZip compression in the player settings (So go to File > Build Settings > Player Settings > Player > Publish Settings > set Compression Format to Disabled.

I assume when the bug gets fixed the Gzip can be turned back on. Then, following the link from Masked Mouse above, I went there, found the IIS Uncompressed section, and copied and pasted all of that text to a new Text Edit file (I work on a Mac, but not posting to Apache server in my case). Here is the link to the discussion about the bug > Uncaught ReferenceError: unityFramework is not defined at HTMLScriptElement.script.onload (WebGL)

I saved the file, naming it web.config and then copied that up to my server into my build folder. When I reloaded the page, it worked.

8

To anyone following this- after chasing my tail on this exact issue for a week and doing what everyone mentioned above (as well as a few other things.) Here is the apache config that actually worked for me:

<IfModule mod_mime.c>
AddType application/wasm .wasm
AddOutputFilterByType DEFLATE application/wasm
</IfModule>

If you have turned off compression to work around the bug and have the line “AddEncoding br .wasm” in your config, it will throw the wasm error in any browser that isnt Firefox.

9

How do you find and copy the edited text file to the server? I have my .config file I made from the link, but how do I use/apply it to the build? Thanks

1 Like
10

I don’t know what is an apache config. Where should I put this code?

1 Like
11

I’d also like to know where to put this code.

Been having the issue with my current project. I’ve tried all compression formats, hashes and no, development and release builds, I’ve tweaked the eneable exceptions and webassembly arithmetic exceptions settings, I’ve tried everything.

My game sometimes runs the first time from my disk but won’t run a second time. It won’t run even once if I post it online.

MY WORKAROUND:
This might not work for everyone but I did get a stable build doing it this way.
First of all, I used Unity’s Cloud Build service. Building locally didn’t work, but on Cloud did.
Default player settings didn’t work even on Cloud. I’m not sure which of these was relevant, but these settings combined worked:
Enable Exceptions: None
WebAssembly Arithmetic Exceptions: Ignore
Compression Format: Brotli
Name Files as Hashes: false
Data Caching: True
Debug Symbols: false
Decompression Fallback: true

1 Like
12

A few things in this thread:

I have been very vocal in our team that we should delete the whole Decompression Fallback feature from Unity. As result, when we refactored the loader in 2020.1 (iirc) it was at least disabled by default. The reason is that it is a bandaid to hide a core problem under the rug and it lets the developer forget about needing to fix things up later. Basically doing a grave disservice to developers.

What Decompression Fallback does is that it decompresses the downloaded content in JavaScript, if the hosting web server was not properly configured to advertise compression in HTTP Content-Encoding response header (and as a result, user’s browser did not decompress the content in native code). This has big problems:

  • it is SLOW on desktop devices,
  • it is SUPER SLOW on mobile devices and burns battery at startup,
  • it prevents the use of WebAssembly streaming compilation, where the .wasm file is compiled into the browser already while it is being downloaded; a feature that usually makes it look like compilation time was instantaneous, and one just had to wait for the network download.

We have talked a lot about Unity’s “Performance by Default” philosophy, and the Decompression Fallback certainly is at the opposite end of the spectrum of that. Sure, it made the build start up, which one might argue is better than not starting up at all; but the root issue is that it might hint a developer to call it a day right there, and the real hosting problem would not then get addressed.

To fix the situation properly, one should always disable the Decompression Fallback, and then update the web server configuration to properly advertise Content-Encoding: gzip (or br if using Brotli), and the respective Content-Type headers.

Agreed, looks like this issue is in our QA queue atm.

To debug all these kinds of loading errors, the web browser console and the Network tab are your friends. Use the browser console to find if there are any site errors, and the Network tab to verify what files got downloaded from the server, and what HTTP Response Headers they were served with.

That will help you figure out what is missing from the proper configuration.

3 Likes
13

Any way we can add to your “vocalisation” about this? I wholeheartedly agree with everything you said about the decompression fallback, it shouldn’t be an option, much less activated by default.

1 Like
14

I am planning that we would add a warning box next to the option to mention that it should not be used in production. Maybe that will remind users as long as they have that enabled. (and keep it disabled by default)

2 Likes
15

Sometimes just for tests I run builds on local servers with no configuration, so I do like this feature, but when on the actual production server, removing this code would be better.

16

I’m building a WebGL game, that’s hosted on an AWS bucket. The only way I can get it to load from there is if I enable “Decompression Fallback”.

From what I understand from this thread is that I shouldn’t enable it but I can’t get it to work without it.
Any advice on what I should do?

17

I have same issue too…
I change compression disable but still not working…

1 Like
18

While I agree with the concept, Decompression Fallback was the only way for my client to get his WebGL game downloaded. Yes, it’s a server configuration problem, but I haven’t been able to find a solution anywhere. I dare say it’s a trivial matter of updating the Content-Encoding and Content-Type on the server, but my client has access to a CPanel admin page, which looks to be allowing new content types to be added, but no matter what combination of entries he makes, he can’t seem to get the compression working. And of course, then that falls back on to me, rightly or wrongly, and I’m now having to try and figure out how to get something that should be simple, working. He thinks it should “just work”, and I don’t blame him.

So, after all of that, is there any recommendations/instructions for the configuration of a system that has CPanel?

19

anyone found a decent solution? i only get this error when my game is opened through facebooks browser. funny thing is that its only on this game in particular event though it loads on desktop and mobile browsers. i dont know what to do!!!

in case someone might help this one http://todiktamo.slaga-games.com/ doesnt open through fb browser

and http://showcase.slaga-games.com/ works just fine. both use 2020.1.4f same build settings. im losing my mind. i tried some other builds that i had already given to clients and they worked fine in their hosting services but when i upload them on mine they dont work

20

Just want to bump the thread: I tried to build a demo for WebGL with both 2019.4 and 2020.2: 2020.2 fails and raises this error no matter what I try, and 2019.4 is working no problem: this has to do with a bug in the new version

1 Like