Offline does not mean "install a web server and run over localhost"

[answerquest]

"Offline" means if someone double-clicks a file and all the scripts and tiles are properly in place, then it should work. Without needing to install and deploy a web-server. That is not something regular people do. Regular computers don't have python installed. The whole intention of taking WebGL offline is to take 3D maps to places beyond the internet divide. Leaflet, Mapbox etc are all working fine when someone just double-clicks the html to open in a web browser. Why then does WebGL have an artificial restriction created inside its javascript to prevent genuinely offline operation? And why is the user being instructed to do a difficult workaround instead of just fixing the code?

[klokan]

The web-browsers does not support loading of WebGL textures from JavaScript via file:// protocols for security reasons. That is a fact. The code can't be fixed as you request.

Users must open the project from http:// protocol.

The only alternative is to instruct the users to turn off the security restrictions of the web browser, which is a dangerous thing. Here is how to do that: https://github.com/mrdoob/three.js/wiki/How-to-run-things-locally

Feel free to provide a properly tested pull request improving the index.html alert() and the README.md documentation for other users to realise there is this second option, if you think this is easier for the people. This is an open-source project.

[answerquest]

Hmm.. But I've seen those security restrictions being a blocker only when trying to load local .json files, inside of the javascript code. The javascript files we include by <script src=... don't get blocked. And neither do the map tiles (png or jpg files). Maps using local tiles, running on Leaflet.js, Openlayers or Mapbox all work locally without any issues when we're not loading any external .json file. When we save their .js and .css files to local path, they become fully offline (not requiring any server also). By "textures" I assume you're referring to the local tiles (applied to the use case of local tiles to render on a 3D globe).

So not able to understand why if Leaflet doesn't throw up a security issue, why would WebGL. On my end I have one web browser (Firefox portable) with the security settings kept off for testing, and another with them being on (Chrome). The local leaflet maps work fine on both browsers. And the WebGL, referencing the same tiles, is not working even on the browser where security settings are off. When I turn on a local server and run from there, it works, so there's nothing wrong with the code.

I don't think this is a technical issue, and I don't think there's a technical "impossibility" here. So I suggest that WebGL should avoid doing the browser's job of policing. If the security settings are in force (by default), then it will error. If not, it should proceed as normal. Checking for http:// origin is not WebGL's job; it should be left to the browser. Please take this into policy or meta discussion if appropriate; please allow other current project contributors to deliberate over this. If other open source mapping technologies are not doing proactive policing, then why is WebGL?

[klokan]

Don't mix general WebGL HTML5 technology in web browser with our WebGL Earth project. Google about the subject or try to change the code and you will see.

If you turn off the alert() in index.html, on a normal browser only a silent error message will be in console, but no alert - so the user will thing the project does not run as no globe will appear.

As I said - feel free to provide a pull request with improved code in index.html using try catch in javascript to alert people about the security problems.

[answerquest]

Oh! Sorry.. can you please redirect me to the WebGL HTML5 project then? Searching for it landed me here