Unity WebGL build works fine on Chrome 65, but stalls on Chrome 66

Hi
I have a Chromebook app that has been working for a long time.
However in the latest Chrome 66 betas it has stopped working.

We are building it using Unity2017.2.0p4 (and I have tested Unity2017.2.2p3 as well with the same result).

The build is working fine in Chrome 65 and earlier versions, but can no longer load in Chrome 66.
No errors are thrown - the only difference in the console log output between the two logs is that on Chrome 66 I get this log:

[webgl] The AudioContext was not allowed to start. It must be resume (or created) after a user gesture on the page. https://goo.gl/7K7WLu

The log is printed a few ms after the GL features have been dumped to the log - and shortly after loading our application stalls.

Have any of you seen this behavior before?

 

https://forum.unity.com/threads/chr...on-66-may-block-audio-for-unity-webgl.517758/

Doesn't crash for us though, just doesn't play the audio. The error still happens on the dev branch fwiw.

 

And the version 66 of chrome come in a week : https://www.chromestatus.com/features/schedule

All game made with unity 2017.x.x and up will be without audio? ^^ (will be funny if it happen )

 

You just need a landing page. It seems to work if a user clicks on a link to launch the Unity WebGL content. It only blocks it if you navigate directly to the Unity WebGL content (e.g. copy and paste the Unity WebGL content's address in chrome's navigation bar).

 

Thank you for your reply - good to know that it is not the audio warning that blocks the application from launching.
We must have some other issue blocking the application on c66 then.

On startup our application sends a message to js where some code is executed, and then the js sends a message to unity, this pattern is repeated a few times.
This has been working fine for many Chrome versions, but has stopped working for us on c66 - the Unity gameobject to receive the message is not instantiated and our app startup flow halts.

I have tried building with full exception support - that gave me no extra information.
Then I tried building webasm - Still not launching on c66
Then I tried raising memory limit - Still not launching on c66
Then I tried lowering memory limit - Still not launching on c66
Then I tried setting GLES 3 only - Still not launching on c66
Then I tried setting GLES 2 only - Still not launching on c66
Then I tried setting GLES 2, GLES 3 - Still not launching on c66

Common for all the tests is that the application launches fine on Chrome 65, but not on Chrome 66. The tests were performed on the same machine, using the same user profile.

If / when I find the issue, I will report back here.

 

Hum not sure that this solution will fixe 100% of case because new AudioContext(); is created when the game start the first scene.

_JS_Sound_Init() seem to be called when the first scene is loaded or just before during the engine initialization. Even with a game without sound, this problem happen. Also, you can have different results if you refresh the web browser or if you press enter in the adress bar ect ...

  function _JS_Sound_Init()

  {

      try {

          window.AudioContext = window.AudioContext||window.webkitAudioContext;

          WEBAudio.audioContext = new AudioContext();

          WEBAudio.audioWebEnabled = 1;

      }

      catch(e) {

          alert('Web Audio API is not supported in this browser');

      }

  }

 

I don't think the warning is triggered by invoking new AudioContext alone.

According to https://developers.google.com/web/updates/2017/09/autoplay-policy-changes#webaudio it should still be ok to do that.
But you will have to wait for user interaction and then invoke resume() on the audioContext before you can start/stop audio etc.

 

I almost forgot to write our solution here.

We managed to find a workaround for the "no longer loading" issue in Chrome 66.

It was not Unity related at all.

We had a HTML splashscreen that was displayed while Unity was initializing - and apparently in Chrome 66 they have changed the behavior compared to previous Chrome versions.

In Chrome 65 this was working just fine. But in Chrome 66 the code in the webgl build was almost not getting any resources. So only the very first few of the gameobjects in our loading scene got to call their Awake methods - but none of them got to invoke the Start method.

We also tried starting some coroutines in Awake that would simple log a line to console every 2 seconds.
It was easy to tell when Chrome 66 was "optimizing" resource-distribution as the log messages stopped being printed to console when the unity element was hidden by an image e.g. and started printing the messages as soon as we removed the element hiding it.

As soon as we removed the splash screen using Chrome inspect tools the unity code started initializing.

Our 'workaround' for production was to move the splash screen image that covered the webview with the webgl code in it in the DOM, and then using CSS transforms translating it back into position (transform does not modify the DOM). That way Chrome 66 would think the webview was visible to the user and gave the webview resources to actually start and our splash screen was still working.