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

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

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 16 (11 by maintainers)

Commits related to this issue

Most upvoted comments

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

Ok better now!

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