Closed catloversg closed 1 week ago
Why is this not a problem for [2]? I'm guessing it's because of Electron's custom request handler, where we allow file:// access to the game's local resources, but lock it down otherwise.
Going forward, if we want to support [3] that may need to be the answer: start distributing the electron build instead of just the web files. File:// access is incredibly restricted (for good reasons), making it very hard to use any modern webpage without a server.
You are right. Our custom request handler handles file:// requests, so the Electron app does not have this problem.
Bitburner is a web application. A player can play it via:
[1] and [2] are the easiest ways to play this game, while [3] is only useful in some very special cases. After #1216 is merged, the game crashes when loading via file://. To enable TS and JSX support, we use swc-wasm, so we have to load a WASM file. However, WASM files cannot be loaded via file:// due to the same-origin policy.
Technically, I can refactor the codebase to make TS/JSX support optional and disable it when the game cannot load the required WASM file. However, I think it's not worth the effort. The refactoring will be complicated, and [3] is not a usual way to play our game. If a player (or contributor) needs to open the game in this way, they can use these workarounds:
security.fileuri.strict_origin_policy
inabout:config
page totrue
.--allow-file-access-from-files
.Note that these workarounds have their own problems:
privacy.file_unique_origin
. The new settingsecurity.fileuri.strict_origin_policy
may also be removed or changed in the future.I created this issue as documentation for this new behavior change. If there are reports about this problem, we can link this issue.
@Snarling @d0sboots @gmcew FYI.