Babylon.js stopped working for me on chrome windows 10

I kid you not, I am unable to open any babylon projects on my windows 10 machine using chrome. At first I thought it was localhost not working on chrome, then I thought it was a bug in my react scripts, and then I tried opening a babylon playground on chrome and it just hung there the same way it does on local host. After waiting about 5 seconds I get the “Page is unresponsive” error message with the RESULT_CODE_HUNG error code being displayed.

I narrowed it down to the BABYLON.Engine class constructor. That’s where it starts to hang for me on localhost.

Things I did:
Disabled all my extensions.
Reinstalled Chrome
Tried using Chrome Canary
Restarting my computer
Tested on Firefox (it works)
Tested on Mac (it works)

EDIT: I am having the exact same problem on the Microsoft Edge Browser.

1 Like

Seems pretty bad … :frowning: When did this start happening ? do you see any logs in chrome://gpu ? what version of chrome is it ?

Last night. So bizarre :confused:
Version 103.0.5060.134 (Official Build) (64-bit)

I’ll check the GPU Logs in 20 mins once I’m back at my desk, I appreciate you looking into this.

Are you referring to the logs at the bottom of the page chrome://gpu:

Log Messages

  • GpuProcessHost: The info collection GPU process exited normally. Everything is okay.
  • GpuProcessHost: The info collection GPU process exited normally. Everything is okay.|


I don’t see any particular error. I can make a video recording though if that would help… it literally just hangs, and the document itself won’t even load.

@sebavan I just reverted back a few commits in my project and it started to work again. Sorry I didn’t realize that earlier. I just don’t know what code change I made that’s causing such an issue :confused:


On one side I am so relieved it is in your project only :slight_smile: but on the other one, it seems scarry this can happen :frowning:

1 Like

So the issue came back again while I was hunting for the commit that might be causing it. The weird thing is I’m on a commit from a few weeks ago.

I even deleted my node_modules directory and reinstalled everything. I’m starting to wonder if it has something to do with the global connection limit a page is allowed to use.

What makes this so frustrating to debug is that I literally cannot see anything that happens while the page freezes. I tried to take a performance snap shot use their page reload button from within the profiler and that just crashed after it used 9G of memory. Going to try again but after commenting out a bunch of the physics code.

EDIT: Not sure if I’m jumping the gun here by posting this, but at the moment it seems like the culprit was Yuka.js. I commented out the code that loads up the ai navmesh and literally everything started working again fine. But I don’t understand how that blocked me from being able to load Babylon.js playgrounds. None of this makes sense at all lol.

1 Like

My project also just started hanging really bad (like chrome or brave goes unresponsive many many times), both locally and deployed, on win11. It loads eventually, after like 3 minutes. Playgrounds do the same.

I wasn’t sure what to think, as it only seems to have affected this machine; android, ios, ubuntu and win10 are all still functioning normally.

The problem seems to come and go…

1 Like

That is actually identical to what I experienced. I found today that the page does eventually load - after about 3 minutes.

1 Like

By chance are you also using Yuka.js?

No sir.

All of their examples and showcases are stalled out for me though.

I’d like to figure out what we have in common.
Are you also using a Linux sub-system?
Does your page load in third party plugins via iframes?

Whatever it is stops all the online playgrounds from working normally but also affects localhost. Then other times while debugging it’ll seem to have gone back to normal after removing a script or two.

I just disabled some scripts and it loaded fast as ever, put the scripts right back exactly as they were, and it still loads fast as ever…

That’s one odd duck. Clearing the cache normally didn’t help but doing that did somehow…

That fixed it in chrome apparently but not for brave

1 Like

I managed to capture a profile. That long running task somehow acquires 54 MB of memory.

Whelp, I’ll certainly stay tuned to this one lol.

Best luck to you friend.

(note: just checked again, problem came right back)
When it finally loads into any tab, it will refresh normally and new tabs open normally.
As soon as I close all the tabs with it loaded, opening a new tab megastalls again.

This works for PGs as well - any tab with BJS loaded allows other tabs requiring BJS to load normally, close all BJS tabs and any new BJS tab stalls.

1 Like

Nothing makes sense here :slight_smile:

Basically to sum up, it seems like on win11 Chrome opening a default playground takes ages as long as there are no other tabs already openened with Babylon ???

@arcman7, @withADoveInOneHand can you confirm ?

@RaananW, @Deltakosh can you repro on win11 ?

I do not repro

Can’t repro. and I find it hard to believe that different tabs can influence the playground. If that’s the case, chrome’s sandboxing doesn’t work.

I’m still on windows 10, as I’ve heard 11 is still a bit buggy. Are you all on 11?

Regarding the multiple tabs, I hadn’t noticed that in particular, but I’m going to try it out the next time the bug comes back.

1 Like

Correct, the first BJS tab to open takes forever.
Once one BJS tab is open, that tab and all other tabs behave normally.
Close all BJS tabs, and opening the next one takes forever again.

Seems to affect Chromium browsers only.

Very odd.

1 Like