Babylon.js: Poor assumptions about file protocol lead to failure.

[emackey]

Some environments allow local file access from JavaScript. In particular, Electron-based environments, such as the HTML preview window in Visual Studio Code, allow this.

There are at least two different places in Babylon where a poor assumption about the presence of file: in a string leads to local file access failure. One is on line 460 of Babylon.Tools.LoadImage and another is on line 540 of Babylon.Tools.LoadFile.

The presence of file: leads Babylon to look in FilesInput.FilesToLoad, which is not correct for this case. The intended behavior in this use case is to send the full XHR request to the file-protocol URL as-is.

For Windows-based local-drive filenames, this problem can be worked around: The Windows drive letter is enough of a clue to Chromium to load from the local file, even without the file protocol being specifically named on the front of the URL. But on Mac/Linux/Unix systems, or even on Windows network shares, there is no drive letter on the front of the URL, and the URL ends up looking like a host-relative root path, not a file-protocol path. Adding an explicit file: protocol to the front of such URLs is the only available fix, but Babylon sees that and refuses to issue an XHR request at all.

/cc @bghgary @sbtron This is deeply related to the issue blocking the glTF Extension for VSCode from working on other platforms, see https://github.com/AnalyticalGraphicsInc/gltf-vscode/issues/58#issuecomment-345111944

[deltakosh]

An easy to implement fix could be to add a general flag in the engine to tell it to no uses filesInput if file:// is found
So in election kind of environment you could just set this flag to true

[deltakosh]

Or even better :
We could try first to load from filesInput and if not found then simply issue an xhr
Thoughts?

[emackey]

Both sound good. I wonder if other devs would want the auto-fallback, or would want control with a flag?

I think either one would work for me.

[deltakosh]

I'll give it some thoughts and implement one asap:)

[emackey]

(Unrelated but, thanks for babylon.max.js in the npm package, that's super helpful!)

[emackey]

Awesome. Did you want to fix Tools.LoadImage too? Seems like the same logic there.

[deltakosh]

My bad I forgot about this one

[deltakosh]

Ok better now!

[emackey]

Thanks!

[pascalbayer]

I'm facing the same issues for private static _loadData in /src/Loading/babylon.sceneLoader.ts line 345+.
A test on my machine showed that a refactoring of line 406 from if (fileInfo.rootUrl.indexOf("file:") === -1) { to if (fileInfo.rootUrl.indexOf("file:") !== -1) { fixes it.
If you can confirm that this change makes sense, I can create a PR for it. It would be beneficial to being able to use the scene loader for our headless jsdom tests to load local test assets without having to spin up a local server for serving the assets.

[deltakosh]

Not sure about that fix..We still need to detect the present of real files. Would love to review a PR as this will be easier to discuss over ;)

[emackey]

@pascalbayer This issue is believed already fixed and closed. Can you share a reproduce case where it's still broken? Are you using an old version?

[pascalbayer]

@emackey This can be reproduced on the latest 4.0.0-alpha.6 by loading a file with rootUrl file:// via SceneLoader.ImportMeshAsync(). I would be happy if there is a workaround that I'm not aware of.

[pascalbayer]

Proposal to fix the described behavior: #5468

[deltakosh]

This is a perfect fix! Merging!

[pascalbayer]

Thanks @deltakosh! Looking forward to see it in the next preview release