WebGL Stops loading if browser looses focus

That's the issue. I have 'Run in Background' checked. Is there a way to fix this? I could possibly start with an empty scene and stream the next one in. This didn't use to be an issue, I would direct users to click the link and come back to it a short while later so they wouldn't loose interest. Now if the browser looses focus or if they even switch tabs it never loads. Solution?

 

I wondered if it was my host or browser, but it's not. The 1st link below was build in Oct of 2016, possibly 5.6? The 2nd with 2017.3.1, both will take a little time to load. Come back to the first one, and it's be there. The 2nd one won't if the browser looses focus or you switch tabs. This happens with the Unity Minimal WebGL template and a custom one I've been using. And on Chrome and Firefox. They are on the same host.

http://www.virtualziggurat.com/Projects/VirtualCity/Unity/index.html

http://www.virtualziggurat.com/Projects/Nuclear-Power-Plant/index.html

 

The problem is caused when publishing to WebGL 2.0. I also noticed that it behaved oddly when changing the size of the browser window, stretching and squeezing. I thought that was an issue with the template i'm using, but I'm not having those issues when I build to 1.0.

So.. yea, that's disappointing.

 

Yes, that's correct.

 

I haven't gotten a chance to post a bug report yet. In the past that process has been disheartening. I don't know exactly how I could create a scene to include that would clearly highlight the problem. Has this been looked into at all for any other reasons on your.

Could it have anything to do with my host? Would someone be willing to provide a simply WebGL 2 build I could post on my host's server? Or I could provide one for someone else to post in theirs to test? I'm grasping at straws here. I need content I send out to be reliable. Thanks.

 

I'm not sure if our issue is exactly the same as the issue topofsteel had.

We had a bug reported in our webgl extension for Chromebooks on Chrome 66. In Chrome 65 everything was working fine. But in Chrome 66 our extension would not start. No errors were logged - actually almost nothing but the GLES log was logged. We ended up adding Debug.Log to all our Awake methods and Start methods. And using those we could see that only the Awake methods on our loading scene scripts got called and then Unity stalled/got silent.

We identified the issue to be caused by our html splashscreen that was shown on top of the Unity webview while Unity was initializing. This has been working fine in Chrome 65 and previous versions back to 49 where we started deploying our extension.

But in Chrome 66 apparently something have changed. As soon as we removed the splashscreen div that was hiding the unity webview - the Unity engine was given resources and started executing again.

As time was a little short (Chrome 66 is about to be released - and some of our customers customers are using beta channel releases that are already on Chrome 66) we ended up making a workaround for production in our CSS. We simply positioned the image on top of Unity a few pixels to the right (so a little of the webview was visible if the DOM was checked) and then using CSS transform we moved the image back into the proper position (CSS transform leaves the DOM unchanged).

This approach is working for us (it would also have worked if we had the splash screen in Unity instead of making it in HTML). Unfortunately Unity is a bit slow to launch on some of the cheap Chromebooks where our application is to be used so our customer wanted us to find a 'faster' way of giving the user load/initialize feedback.