Using Cesium in a local application silently fails to display entities

[cguinnup]

As mentioned in the forum ( https://groups.google.com/forum/#!topic/cesium-dev/iNuC3h8FQ4U ), I'm attempting to use Cesium in a local application using Chromium with cross origin requests and disk access enabled. However, accessing Cesium locally causes entities to never display, due to approximateTerrainHeights.json silently failing to load.

If I change loadWithXhr.js to accept the a zero HTTP status when a URL starts with "file://", then Cesium starts working as expected. I'd like to pull request this, assuming Cesium will accept it. Hope we can keep local use alive.

[hpinkos]

There's been some discussion on this before, and I don't think it's a chance we want to make. See #5831 (comment)

[cesium-concierge]

Congratulations on closing the issue! I found these Cesium forum links in the comments above:

https://groups.google.com/forum/#!topic/cesium-dev/iNuC3h8FQ4U

If this issue affects any of these threads, please post a comment like the following:

The issue at #5830 has just been closed and may resolve your issue. Look for the change in the next stable release of Cesium or get it now in the master branch on GitHub https:/AnalyticalGraphicsInc/cesium.

I am a bot who helps you make Cesium awesome! Thanks again.

[cguinnup]

Well, since developers have apparently bumped into this before, what about presenting an error when file:// load attempts give a bad status but actually have content? With a message such as "Cesium does not support browsers that return an invalid HTTP status when accessing files locally, please use Electron." Currently it's a silent failure, since the assets actually load but XHR throws away the response.

[hpinkos]

That's a good idea, thanks @pizza2code! @emackey what do you think?

[shunter]

The approach in the original patch seems reasonable to me as-is. I looked through the spec briefly and it seems like returning status 0 on a successful request makes Chrome out of spec, but that's never going to be fixed at this point.

Realistically, the status property is only applicable to HTTP(S) requests, and so it shouldn't be consulted with other protocols. For file XHR loads, errors will be reported via the onerror callback. jQuery actually appears to treat a status of 0 as "success" universally in their XHR code, which is pretty sloppy, and we can do better than that, at least.

So for the actual fix, probably just skip the if check if the protocol is file. For files if we're in the onload, it succeeded.

[cesium-concierge]

Congratulations on closing the issue! I found these Cesium forum links in the comments above:

https://groups.google.com/forum/#!topic/cesium-dev/iNuC3h8FQ4U

If this issue affects any of these threads, please post a comment like the following:

The issue at #5830 has just been closed and may resolve your issue. Look for the change in the next stable release of Cesium or get it now in the master branch on GitHub https:/AnalyticalGraphicsInc/cesium.

I am a bot who helps you make Cesium awesome! Thanks again.

[thw0rted]

I just made a comment on the PR above and @hpinkos has made a small update as a result -- once merged, loadWithXhr will also treat status=0 reads against relative URLs as success, when the current origin is file://. That's great and solves a problem I was having with running my project from the local filesystem in Chrome.

I'm running into a second, less severe issue. When running from Firefox, the security model is totally different. It always allows XHRs to other files in the same directory as the local source, so that makes things nice and easy. Problem is, I'm seeing a similar error to what @pizza2code saw in the original post, failure to load approximateTerrainHeights.json and IAU2006_XYS_15.json -- but in this case, it's "XML Parsing Error: not well-formed". I'm not clear on where exactly it's trying to treat the JSON as XML; my sourcemaps aren't lining up with my (custom) minified Cesium, so it might take me a little more time to figure out what's going on here.

Is anybody else trying to run Cesium locally? If so, do you get the same errors in Firefox? The good news is that this failure actually doesn't kill Cesium, it just means you're stuck with a flat ellipsoid, which isn't so bad when you're using ultra-low-res imagery anyway.

[thw0rted]

I'm not sure how the Firefox issue ties into the Chrom(e|ium) one but the mega-thread on the Chromium tracker about this issue brings up a very interesting point -- if you can work it into your build process, you could store this JSON as JSONP with a hard-coded callback method. It's certainly ugly, but it sounds like probably every browser will allow a file:// page to insert a <script> tag that points to a resource at a relative path.

Alternately, maybe it would be possible to alter the build process so that the tool you use (Webpack in my case) inlines the JSON content of these two files in the end product, rather than trying to load them dynamically? I haven't spent the time to dig into why they're being loaded via XHR. Maybe there are deployments where they wouldn't be used, so they're loaded dynamically to allow the possibility to shrink the total download size? In that case, would aggressive tree-shaking at build-time achieve the same effect?