WebGl application failing since upgrade to 6000.0.35f1

Unity Engine
, , ,
1

With only the update from 6000.0.34f1 to 6000.0.35f1 (still there in 36f1), if webGLDecompressionFallback is set to 1 , we are getting the exception :

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'match')
    at Object.cacheControl (WebGL.loader.js:1:953)
    at T (WebGL.loader.js:1:40660)
    at P (WebGL.loader.js:1:44684)
    at WebGL.loader.js:1:47416

on line

cacheControl: function(e) {
            return e == b.dataUrl || e.match(/\.bundle/) ? "must-revalidate" : "no-store"
        },

and the application does not launch.

2

Hi, @oliver-noodle. If this is a consistently reproducible issue, please report the bug via the Bug Reporter (“Help → Report a Bug…” in the Editor). Make sure to attach the project and write reproduction steps (or attach a reproduction video). Cheers!

3

Be sure to make a clean build and also try after deleting the Library, just in case.

4

I encountered the same problem and found a solution，Add a new attribute in the ‘create UnityIstance’ section of index.html，like this

      createUnityInstance(document.querySelector("#unity-canvas"), {
        arguments: [],
        dataUrl: "Build/output.data.unityweb",
        workerUrl: "Build/output.data.unityweb",
        frameworkUrl: "Build/output.framework.js.unityweb",

I found out when I was breaking the webpage that the new output.loader.js file has an additional method to check the workerUrl property.

5

Unity 6000.0.37f1
Confirming, have same issue:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'match')
    at Object.cacheControl (ASTC.loader.js:1:952)
    at R (ASTC.loader.js:1:110686)
    at N (ASTC.loader.js:1:114710)
    at ASTC.loader.js:1:117442
6

Same issue ! Unity 6000.0.37f1

8

Can confirm that Azurs’s solution fixes the issue on my side.

9

In fact, you can reproduce the crash in an empty project created with Unity 6000.0.37
if you enable data caching AND decompression fallback.

Even if you add the “arguments” attribute

10

I have created a bug report : CASE IN-94965

11

Facing the exact same issue in 6000.0.37f1, only solution is to disable decompression fallback. Any updates to this?

12

Had the same issue on 37f1. Downgrading to 34f1 solved the issue.

13

I confirm the Azurs solution, make sure to add arguments and workerUrl properties (which is a copy of the dataUrl property) in the configuration object.
Don’t know what the workerUrl is for, because it’s not used anywhere.

createUnityInstance(document.querySelector("#unity-canvas"), {
  arguments: [],
  dataUrl: "Build/myGame.data.unityweb",
  workerUrl: "Build/myGame.data.unityweb",
  frameworkUrl: "Build/myGame.framework.js.unityweb",
  codeUrl: "Build/myGame.wasm.unityweb",
  streamingAssetsUrl: "StreamingAssets",
  companyName: "Company",
  productName: "Product",
  productVersion: "1.0.0",
  // matchWebGLToCanvasSize: false, // Uncomment this to separately control WebGL canvas render size and DOM element size.
  // devicePixelRatio: 1, // Uncomment this to override low DPI rendering on high DPI displays.
});

Alternatively, If you don’t do many iterations, you can also remove the workerURL check from the loader.js
to resolve this error.
(By unminify the loader.js, you can remove the lines 3376 to 3383, he can vary depending of the options you have checked in the player settings)

R("workerUrl").then(function (e) {
    var t = URL.createObjectURL(new Blob([e], { type: "application/javascript" }));
    (w.compressedWorkerUrl = w.workerUrl),
        (w.workerUrl = t),
        w.deinitializers.push(function () {
            URL.revokeObjectURL(t);
        });
}),
14

Hi,

We track this bug in this ticket now: Unity Issue Tracker - The Player freezes on load when building Web platform

We are currently looking into it and I hope I can give you an update soon.

Edit: Oh it is actually the exact ticket that was created by @Zarbuz. Sorry for the confusion :slight_smile:

15

I’m using 38f, I have same issue

but I avoid this with disable decompression fallback or enable native c/cpp multithreading
I dont’t know why this setting avoid error but this work

16

is this fixed in 40f1? any update?

17

Still broken on 40f1, but Azurs workaround works.

And based on the ticket info, it should be fixed on 42f1.

18

Can replicate in 6000.0.41f1. 6000.0.42f1 has fixed it apparently, but no download for that currently.

19

Life saver! Thanks