-
Notifications
You must be signed in to change notification settings - Fork 247
Description
What happened?
When crossOriginIsolated is false, it loads the file web-ifc.wasm.
This appears to be working correctly, since it uses the path defined in configuration.
But when crossOriginIsolated is true, it attempts to load a different file, web-ifc-mt.worker.js.
In this case, it does not use any configured path, instead it attempts loads it from the current path.
For example, if the user is currently at /some/page in the browser, then it will try to load /some/page/web-ifc-mt.worker.js.
This is almost always the wrong thing to do, since this path is not going to resolve in any typical app.
This leads to an error in the console, and the library does not proceed executing.
This effectively prevents this library from being used in apps that are deployed with proper security headers and CORS headers.
If the code contains a hard coded path, then it should be /.
Because the most common setup is to host the worker and wasm files under the root, like /web-ifc-mt.worker.js.
But it would be much better to make the path configurable, just like the path to the wasm file.
This is a basic requirement for any library that has to load load static files like this.
Version
0.72
What browsers are you seeing the problem on?
Firefox, Chrome
Relevant log output
Anything else?
The problem seems to come from this piece of code: https://github.com/ThatOpen/engine_web-ifc/blob/0.72/src/ts/web-ifc-api.ts#L380-L392