Safari (Mac) Bug: GLB Fails to Load After Create Screenshot Using Render Target

Bugs
1

Hello dear community,

I hope you can help me somehow. After hours of searching and reading through forums, I couldn’t find a solution to my problem. The issue occurs exclusively on Mac with the Safari browser:

When I render a screenshot using CreateScreenshotUsingRenderTarget and then try to load a GLB into the scene, the GLB does not load. The console shows the following error log:

BJS - [14:19:58]: Unable to load from https://www.babylonjs.com/Assets/DamagedHelmet/glTF/DamagedHelmet.gltf: undefined is not an object (evaluating 'h._features.forceBitmapOverHTMLImageElement')

How can I solve this problem? I definitely want to render the scene using CreateScreenshotUsingRenderTarget.

Here is the playground for testing: When a screenshot is taken, the helmet is not loaded into the scene.

Thank you for any suggestions!

2

I can’t reproduce it. Here the steps:

  1. Open https://playground.babylonjs.com/#55GIRT#1 in Safari browser
  2. “BoomBox” (.glb) stereo is imported and injected into the scene
  3. Click on “Take Screenshot” button (the screenshot is downloaded)
  4. Click on “Load Helmet” button, the “DamagedHelmet” (.gltf) helmet is imported and injected into the scene

Screenshot 2025-02-04 alle 18.09.47
Screenshot 2025-02-04 alle 18.09.471920×1073 146 KB

Note: the JavaScript errors are not related (they refer to missing source maps of Monaco editor).

Safari version: 18.1 (20619.2.8.11.10)

2 Likes
3

Same experience on chrome.

1 Like
4

That’s strange, it doesn’t work for me and gives the mentioned error log, preventing any GLB from being loaded into the scene afterward.

Safari Version 18.3 (18620.2.4.111.8, 18620)

5

The problem occurs exclusively in Safari. Everything works fine in Chrome and Firefox.

1 Like
6

Sorry, I just saw that sentence in the original message.
Any specific version of Safari? I just tested on 18.3 as well, and it works.

7

Thank you for testing, RaananW! No, I don’t have a special Safari version: Version 18.3 (18620.2.4.111.8, 18620
I guess it must be a local issue on my MacBook.

8

Can you try to clear all cache data or test in a new private window?

  1. Click on the “Safari” menu in the top left hand corner next to the Apple symbol
  2. Click on “Settings…”
  3. A new dialogue box will open
  4. Click “Privacy”
  5. Click on the “Manage Website Data” button
  6. To remove any cached data and cookies from your computer, click “Remove all” (or select “babylonjs.com” entry and click on “Remove” button).

Then close and reopen Safari and repeat the test.

9

Thank you very much for the tip, Simone. Unfortunately, it didn’t make any difference, the error persists. Maybe it’s due to my old OS (Ventura 13.7.3 (22H417)).
It’s complicated. I’m working on a Photoshop UXP plugin where I want to use Babylon. On my test Mac, the mentioned error also occurs in Photoshop. I had read that Photoshop actually uses the Chromium browser. I’m at a loss.

But thank you for the tips and for testing. <3

1 Like
10

I’m sorry. Anyway, if you need to test on Safari browser, you can consider alternative solutions like BrowserStack.

1 Like
11

Hi @Sigko ,

I can reproduce the issue on my old Mac (macOS 12.7, Safari 17.6). At the same time on the new one (w/ Safari 18.3), everything works fine.

I’ll try to dive deeper into the issue later this week, maybe I’ll find something useful.

1 Like
12

Hi @RaananW ,

I think I found the reason why this issue is happening.
The problem is in the dumpTools.ts#L40-L47.
First, it tries to create a new Engine using OffscreenCanvas and in case WebGL is not supported it falls back to normal Canvas.
But the problem is that the previously created Engine (w/ OffscreenCanvas) remains in the EngineStore but in an uninitialized state (_initFeatures was not called, etc.).

This results in 2 engines stored inside EngineStore: #1 - a fully functional Engine used by the main scene, and #2 - an uninitialized leftover created by DumpTools.

Later, when we try to load a new GLB model (or any other action using fileTools), we end up on fileTools.ts#L210 which grabs “broken” engine #2 from the EngineStore and fails on line fileTools.ts#L241 (_features was not initialized in the constructor).

I can see two possible solutions here:
a) remove the engine instance from the EngineStore before throwing an error (thinEngine.ts#L391-L404)
b) handle this situation in dumpTools.ts and remove the “broken” instance from EngineStore in line dumpTools.ts#L44 before creating another Engine instance.

Here is the PG that demonstrates the problem in any browser:

Hope this will help.

2 Likes
13

Hello @dgorbash,

Thanks for your effort! The fact that the problem seems to be identified definitely makes it easier to test (on the PC). However, I unfortunately don’t have any idea on how to implement any of your solutions.

14

Ha! Interesting. Great catch! Let’s fix that. i’ll have to see how I can validate that.

1 Like
15

Want to test a fix? https://playground.babylonjs.com/?snapshot=refs/pull/16151/merge#55GIRT#4

2 Likes
16

Awesome, @RaananW! It works for me on PC with Chrome and Firefox. I will test it later in Safari and Photoshop on my Mac.

Thank you so much, I’m really excited! :blush:

1 Like
17

It also works perfectly on the Mac with Safari. Now I’m looking forward to the 7.48.0 release. Thanks again @dgorbash, and @RaananW (hab grad gesehen, du kommst aus der Hauptstadt, ganz liebe Grüße aus Johannisthal Nachbar:)). You’re awesome!

1 Like